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(54) Imposition process apparatus for variable imaging system 



(57) The present invention comprises an apparatus 
and method for reproducing master and variable infor- 
mation on a display device, such as a computer network 
or a demand printer. The present invention develops 
first and second sets of template data representing 
associated first and second template pages, respec- 
tively, wherein each set of template data includes mas- 
ter data representing fixed information to be printed and 
area data representing an area of a page in which vari- 
able information is to be printed. A database is devel- 



oped having a number of entries, each of which 
represents variable printed information and the display 
device is responsive to the sets of template data and the 
database to display the first and second template pages 
with selected variable information. The fixed and varia- 
ble pages may be converted to TIFF format and 
imposed according to an instruction set. Alternatively, 
the fixed and variable pages may be "imposed-on-the- 
fly" as they are processed by a RIP. 
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Description 
Related Applicationfi 

This application Is a continuation-in-part of U.S. application serial no. 08/478,397. filed June 7, 1995 and a contin- 
uation-in-part of U.S. application serial no. 08/627.724. filed April 2. 1996. 

Technical Held 

The present invention relates generally to reproduction methods and systems, and more particularly to a method 
of and system for selectively reproducing images. 

Background Art 



Most printing systems in use today utilize printing plates or cylinders which are engraved or photochemically proc- 
essed to create an image thereon. Ink is then deposited on the plate or cylinder and the Ink is thereafter transferred to 
a substrate, such as paper. In a conventional printing press, a number of pages are printed on a sheet of paper to form 
a signature which is then folded and assembled with other signatures. The assembled signatures are then bound, 
trimmed and finished by finishing apparatus to produce finished books, such as magazines, catalogs or any other 
20 printed and bound matter. 

Often, there is a need to produce different versions of books and/or customized books within a single press run. For 
example, it may be desirable to produce a number of standard books together with a number of books having additional 
and/or different signatures or pages therein. Also, it may be necessary or desirable to provide customized information 
m the form of an address label, personalized information or the like on the inside or outside of finished books. In either 
case, conventional printing systems are not easily adaptable to produce books of these types. 

A printing system which has the ability to produce differing book versions and/or books with customized information 
IS disclosed in Riley U.S. Patent No 4.1 21 .818. assigned to the assignee of the instant application. The printing system 
includes a number of packer boxes disposed adjacent a binding chain wherein each packer box stores a plurality of sig- 
natures. A control is included for controlling the packer boxes to selectively feed signatures onto chain spaces of the 
binding chain so that books of varying content can be produced. Customized Information can be printed on the signa- 
tures by means of an ink jet printer which is selectively operated by the control. Other types of customization can be 
effectuated, such as by inserting or onserting cards or the like. 

Other systems for producing customized books are disclosed in Abrams et al. U.S. Patent No. 3 899 165 Wong et 
al. U.S. Patent Nos. 4.500.083 and 4.674,052. Wong U.S. Patent No.' Re 32,690 and Berger et al! U.S Patent Nos 
35 4.768.766 and 4.789.147. 

Image manipulating systems have been developed which permit gathering of images in an office or home environ- 
ment. For example, conventional word processing programs, such as Microsoft® Word®. WordPerfect® and the like, 
permit a user to import Images into a page and also allow a user to command which pages of a document to print. Iri 
addition, macros (i.e.. a sequence of commands) can be assembled and executed within these programs which can 
allow printing of particular document pages in a certain order. Still further, most word processing programs have merge 
capability wherein a customized image is merged with other standardized information and printed or displayed. As one 
example, customized information in the form of addressee and address information may be merged with standardized 
return address information and printed on a series of envelopes. 

A different image gathering capability provided by CAD (computer aided design) software, sometimes referred to 
as layering." involves the creation and storage of a base page and one or more layer pages. A user can Issue com- 
mands to display or print the base page and one or more of the layer pages simultaneously atop one another to achieve 
an effect similar to the overlay of transparencies so that a composite page appearance results. 

While the foregoing image manipulating systems allow some image gathering capability, none is effective to assist 
in the rapid production of different book versions. Of course, CAD systems are primarily designed for line art and not 
text or graphic images, and hence are of only limited use. Further, if one were to use word processing software to pro- 
duce book versions it would be necessary to issue commands to separately print the pages of each book version just 
before such version is to be produced. That is. a user would have to create and store pages to be included in a first book 
version and then command the software to print as many copies of the first version as are needed. Thereafter, the user 
would have to recall the pages of the first version from memory, edit and store the pages to create pages to be included 
in a second book version and then command the system to print the required number of books of the second version 
Similar steps would have to be undertaken for each other book version to be produced. Alternatively, the pages of the 
different book versions could be created and stored and thereafter printed together. In either event, where many book 
versions are to be produced, such a process would be quite time-consuming. In addition, image importation and merge 
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routines provided as a part of word processing software are adapted for use on a sub-page basis only and hence are 
of only limited usefulness in the book production environment. Still further, data manipulated by word processing soft- 
ware are largely (if not entirely) in symtxslic format As a result, data to be displayed or printed must be first rasterized 
by a raster image processor (RIP), which utilizes complex and time-consuming computational routines which further 

5 increase production time to an economically impractical level. 

Recently, new printing systems have been developed, called "demand printers." which are capable of high speed 
printing of images from electronic representations thereof. The demand printer produces high quality color (or black and 
white) images using a set of fusible toners in an electrophotographic process. More particularly, a web of paper is 
passed adjacent a series of drums, each of which has been electrostatically charged according to an image pattern for 

10 a particular color to be applied to the web. The charge is transferred to the paper and an oppositely charged toner of 
the proper color is brought into contact with the paper. The oppositely charged web and toner attract so that the toner 
is held on the paper as other colors are applied thereto. The toners and paper are thereafter heated to fuse the toners 
to the paper to produce the final image. The web is then cut into sheets (or "forms") and the forms are further processed 
as needed to produce a final product. 

15 Unlike conventional presses which utilize engraved or photochemically prepared plates or cylinders, demand print- 
ers are capable of rapidly printing high quality images of differing content owing to the fact that the images are produced 
by an electrophotographic process. That is. instead of the need to replate and re-engrave a gravure cylinder when a dif- 
. ferent image is to be printed therewith, it is only necessary to change the charge applied to the drums of the printer in 
order to make such change. Thus, different images can be printed by the same printer without significant delays. This 

20 advantage makes the demand printer desirable for use in certain production environments. . 

Warmus et al. U.S. Patent Application Serial No, 08/478,397, entitled "Variable Imaging Using An Electronic Press" 
. discloses an apparatus and method for controlling an electronic press so that fixed and variable information may be 
printed in a simple and effective manner. More particularly, first and second sets of tenpiate data representing associ- 
ated first and second template pages, respectively, are developed. Each set of template data includes master data rep- 

25 resenting fixed information and area data representing an area of a page for variable information. A database is also 
developed having a number of entries each of which represents variable information. The printer is operated in accord- 
ance with the sets of template data and the entries in the database such that the first and second tennplate pages are 
displayed with selected variable information. 

The Warmus et al. apparatus and method generates a page definition language representation of each single page 

30 and thereafter generates a page definition language representation of each imposed fiat, i.e., each side of a piece of 
paper to be printed with two or more pages. Such a procedure can be computationally expensive and may limit produc- 
tivity. 

Summary of the Invention 

35 

According to one aspect of the present invention, an apparatus for controlling a display device comprises first 
means for developing first and second sets of tennplate data representing associated first and second template pages, 
respectively, each set of template data having master data representing fixed information to be displayed and area data 
representing an area of a page in which variable information is to be displayed. The apparatus also includes second 

40 means for developing a database having a number of entries each of which represents variable information and means 
responsive to the first and second developing means for causing the display device to display the first and second tem- 
plate pages with selected variable information. 

Preferably, the causing means includes means for converting the sets of tennplate data and the database into com- 
mands for the display device specifying sequence and content of page display. The converting means includes means 

45 for separating the sets of template data into master files containing master data and intermediate variable page files 
having area data. Further, the converting means includes means responsive to the database and the intermediate var- 
iable page files for deriving final variable page files having content data representing variable information. The convert- 
ing means may further include third means for developing the commands from the master page files and the final 
variable page files. Preferably, one of the final variable page files includes text data representing text to be displayed on 

50 a page and the deriving means includes means for composing the text data. 

The display device may be located remotely from the causing means and further includes means for transmitting 
data over the Internet, an intranet or computer network. The display device may also be a demand printer for printing 
data into a book. 

According to another aspect of the present invention, a method of controlling a display device comprises the steps 
55 of developing first and second sets of template data representing associated first and second tennplate pages, respec- 
tively, each set of template data having master data representing fixed information and area data representing an area 
of a page for variable information. The method also comprises developing a database having a number of entries each 
of which represents variable information and causing the display device to display the first and second template pages 



3 



EP 0 858 041 A2 



with selected variable information. According to another aspect of the present invention, a method for assembling pages 
for reproduction comprises the steps of generating a master PDLfile containing page descriptions of master pages with 
fixed information and generating a variable PDL file containing page descriptions of variable pages with variable infor- 
mation. The method further conrprises the steps of RIPping the master and variable page descriptions in conjunction 

5 with imposition-on-the-f ly procedures which impose the master and variable pages into a book format and transmitting 
the imposed master and variable pages to a display device. 

According to yet another aspect of the present invention, a method for assembling pages for reproduction com- 
prises the steps of generating a master file containing page descriptions of master pages with fixed information in TIFF 
format and generating a variable file containing page descriptions of variable pages with variable information in TIFF 

10 format The method further comprises the steps of generating an instruction set for imposing selected master and var- 
iable pages from the TIFF files, RIPping the selected pages according to the instruction set. and transmitting the 
imposed master and variable pages to a display device. 

Other features and advantages are inherent in the apparatus claimed and disclosed or will become apparent to 
those skilled in the art from the following detailed description in conjunction with the accorrpanying drawings. 

15 

Brief Description of the Drawing s 

Fig. 1 is a block diagram illustrating a prior art method of producing books; 
Fig. 2 is a block diagram of a method of producing books implementing the present invention; 
20 Fig. 3 is a block diagram illustrating an exemplary system for implementing the method of the present invention 

illustrated in Fig. 2; 

Fig. 4 is a block diagram illustrating one of the demand printing systems of Fig. 3 in greater detail; 
Fig. 5 is a generalized diagram of the steps implemented by the method of the present invention; 
Figs. 6a and 6b are elevational views of portions of a sample book that may be produced by the present invention; 
25 Figs. 7a. 7b and 8a, 8b are elevational views of portions of other sample books that may be produced by the 
present invention; 

Fig. 9 is a flowchart illustrating programming that may be executed by a user on a personal computer to create the 
template files 105 of Fig. 5; 

Figs. 10a-10f, when joined along similarly-lettered lines, together represent programming executed by the control 
30 unit 52 of Fig. 3: 

Fig. 11 is a flowchart illustrating the programming inplemented by the control unit 52 to generate a page descrip- 
tion language instruction set specifying which pages should be printed and how the pages should be positioned (or 
imposed) for printing; 

Fig. 12 is a sample window to prompt a user for the information needed to create a pagination file; 
35 Fig. 13 is a flowchart illustrating in detail the programming inplemented by the block 348 of Fig. 11 which deter- 
mines which pages should be printed for a particular record in the press command file; 

Fig. 14 is a flowchart illustrating in detail the programming implemented by the block 350 of Fig. 11 to determine 
whether the pages should be forced to the left or right-hand side of the book; 

Fig. 1 5 is a flowchart illustrating in detail the programming inplemented by the block 352 of Fig. 1 1 to pad the pages 
40 included in the book into a multiple of the number of pages to be printed on a sheet; 

Fig. 16 is a sample window to prompt a user to provide various Information to select imposition and printing styles; 
Fig. 1 7 is a flowchart illustrating the programming implemented to RIP page files to Tiff format for use in "Get Tiff" 
imposition in accordance with the present invention; 

Fig. 1 8 is flowchart illustrating the programming implemented to impose pages using ^'Get Tiff" imposition in accord- 
45 ance with the present invention; 

Fig. 19 is a more detailed t^lock diagram of the print system 79 (shown in Fig. 4) incorporating the imposition-on- 
the-f ly procedures of the present invention; 

Fig. 20 is a flowchart illustrating the standard operation of the Level 2 PostScript® showpage operator; 
Fig. 21 is a flowchart illustrating the program steps implemented by the redefined PostScript® initclip operator 
50 according to the imposition-on-the-f ly procedures of the present invention; 

Fig. 22 is a flowchart illustrating the program steps inplemented by the redefined PostScript® transform operators 
according to the imposition-on-the-fly procedures of the present invention; 

Fig. 23 is a flowchart illustrating the program steps inplemented by the EnableVirtual Device procedure according 
to the imposition-on-the-fly procedures of the present invention; 
55 Fig. 24 is a flowchart illustrating the program steps implemented by the DisablePageDevice procedure according 
to the imposition-on-the-fly procedures of the preserrt invention; 

Fig. 25 is a flowchart illustrating the program steps implemented by the SetPortrait procedure according to the 
imposition-on-the-fly procedures of the present invention; 



4 



EP0 858 041 A2 



Fig. 26A is a diagram illustrating the conversion of a portrait-oriented page to a landscape-oriented page according 
to the SetPortrait procedure of Fig. 24; 

Fig. 26B is a diagram illustrating the conversion of a landscape-oriented page to a portrait-oriented page according 
to the SetPortrait procedure of Rg. 24; 
5 Fig. 27 is a llowchart illustrating the program steps implemented by the setvirtuaWevice procedure according to the 

imposition-on-the-fly procedures of the present invention; 

Fig. 28 is a flowchart illustrating the program steps implemented by the ImposeJob procedure according to the 
imposition-on-the-f!y procedures of the present invention; 

Fig. 29 is a flowchart illustrating the program steps implemented by the ImposeRle procedure according to the 
10 imposition -on-the-fly procedures of the present invention; 

Fig. 30 is a flowchart illustrating the program steps implemented by the MakeNull procedure according to the impo- 
sition-on-the-fly procedures of the present invention; 

Fig. 31 is a flowchart illustrating the program steps implemented by the redefined EndPage procedure according to 
the imposition-on-the-f ly procedures of the present invention; 
15 Fig. 32 is a flowchart illustrating the program steps implemented by the redefined BeginPage procedure according 
to the imposition -on-the-fly procedures of the present invention; 

Fig. 33 is a flowchart illustrating the program steps implemented by the Vsave procedure according to the imposi- 
tion-on-the-f ly procedures of the present invention; 

Fig. 34 is a flowchart illustrating the program steps implemented by the Vrestore procedure according to the impo- 
se sition-on-the-f ly procedures of the present invention; 

Fig. 35 is a flowchart illustrating the program steps implemented by the redefined PostScript® gave operators 
according to the imposition-on-the-fly procedures of the present invention; 

Fig. 36 is a flowchart illustrating the program steps implemented by the redefined PostScript® restore operator 
according to the imposition-on-the-fly procedures of the present invention; and 
25 Fig. 37 is a flowchart illustrating the program steps implemented by the redefined PostScript® grestore and gresto- 

reall operators according to the imposition-on-the-fly procedures of the present invention. 

Description of the Preferred Embodiments 

30 Fig. 1 illustrates a prior art method of producing books, for example, as shown in the above- identified, Riley et al. 
'818 patent. During a publishing step 20, the contents of one or more book versions are determined. Each version may 
comprise, for example, a set of standard or common pages. In addition, some of the versions may include one or more 
additional pages or other customized information. Thereafter, during a preliminary step 22, color correction of color 
images is undertaken together with undercolor removal and screening for halftone images. During a prepress step 24, 

35 page imposition is effected and printing cylinders or plates are prepared. The plates or cylinders are then used during 
a printing step 26 to prepare signatures which are loaded into packer boxes (not shown). As noted in the Riley et al. 
'818 patent identified above, the signatures are then selectively collected on a gathering chain (not shown) during a 
book assembly step 28 and the gathered signatures are bound and trimmed to create the books. The books are there- 
after distrtouted during a step 30 to users via one or more distribution systems, for example, the U.S. Postal Service. 

40 As should be evident from the foregoing, customization occurs during the book assembly step 28, inasmuch as the 
choice of particular signatures to be included in a book is made at that time. In addition, customized information can be 
printed onto selected signatures using an ink jet printer disposed adjacent the gathering chain. Thus, for example, 
addressee information can he printed by the ink jet printer on assembled books so that preprinted addressee labels 
need not be used. Other types of customization can be effected at this time, for example, by inserting or onserting cards 

45 into or onto a stack of collected signatures, affixing a specialized or customized cover on a gathered stack of signatures, 
or the like. Customization at this point in the production process is simpler and less expensive than, for example, sepa- 
rately printing each book version with customized information. 

Fig. 2 illustrates a block diagram of a method 40 according to the present invention which may be used in place of 
the method of Rg. 1 to produce books. The method 40 includes a step 42 which utilizes the output of publishing and 

50 preliminary steps 36, 38 and produces books for distribution according to the step 30 of Fig. 1 . The step 42 creates one 
or more master and variable page files in, for example, a page description language (PDL) such as PostScript® (Post- 
Script® is a trademark of Adobe Systems, Inc. for its page description language) representing pages to be produced. 
In addition, as noted in greater detail hereinafter, a press command file (also referred to as a *book ticket" file) is devel- 
oped which specifies the manner in which data contained within the master and variable page files are to be merged to 

55 produce printed pages. The format of the press command file may be. for example, of the form specified by Barco 
Graphics of Gent, Belgium, which is particularly suited for control of a DCP-1 digital color press manufactured by Xeikon 
of Mortsel. Belgium. Alternatively, the format of the press command file may be of the form specified for control of a Doc- 
uPrint printer, manufactured by Xerox Corporation. Other demand printers include the IBM 3900 or Siemens 2090 Twin 
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or 2140 Twin. It should be noted that the apparatus and method of the present invention are not limited to use with a 
particular type o1 demartd printer or a particular system for controlling such a printer, Inasmuch as the Invention can be 
adapted for use with any type of printer or control whether located locally or remotely 

The master and variable page files and the press command file are converted by a collator and raster image proc- 

5 essor (RIP) into bitmaps which may be stored in a memory. The stored bitmaps are used to control one or more demand 
printers and/or any other type of display device, such as a laser printer, a CRT, an LCD display or the like So that the 
device displays pages having fixed and variable information thereon. Alternatively, the master and variable page files 
may be premerged to create a plurality of combined files each representing a page to be reproduced with master and 
variable information. The combined files can be then sent to any type of printer or other display device, whether local or 

10 remote. Also, the combined files can be converted to a suitable format (e.g., Acrobat® PDF format) and transmitted to 
a remote location using a facsimile machine, e-mail, the Internet/World Wide Web or other transmission medium, if 
desired. Advantageously, the combined files may be transmitted over the Internet or any other networked or linked com- 
puters, such as a company intranet. In this case, an electronic page containing customized data can be sent over the 
internet/intranet to a user based upon user demographic(s), a user search and/or any other identifiable user interest(s). 

75 For example, a customized Internet page could be sent with links to other web pages of interest to a user or a custom- 
ized page may be sent in response to a user search for information on a particular subject. Alternatively, or in addition, 
ads could be generated and sent as a web page to one or more users based upon user demographics. As a further 
example, personnel information concerning a particular employee may be sent to the employee in response to a 
request for information. 

20 If the pages are to be displayed by rendering the pages on the demand printer, the assembled books may be bound 
and trimmed and, if desired, further customized, during a finishing step. 

Fig. 3 illustrates a system 50 which implements the steps 36, 38 and 42 in the method 40 of Fig. 2. A control unit 
52, which may be implemented by a personal computer or another type of conrputer, includes a memory 53 and stores 
therein data representing images to be printed. As noted in greater detail hereinafter, the data may be specified by a 
25 publisher using a personal computer 54 or any other type of computer and may comprise one or more template files 
specifying pages to be produced with master or fixed printed information (i.e., printed information which does not vary 
from book to book of the same version) and variable printed information (which typically varies from book to book). The 
variable information may be stored in a database created by the publisher and the template file(s) specify the locations 
on particular pages tor variable information stored in the database, as noted in greater detail hereinafter. 

30 If desired, image data may be obtained from any other type of device or devices, such as a scanner which scans 
input copy data supplied over a network or any other source. The control unit 52 is further responsive to control and 
makeready files and causes one or more demand printing systenrre 62 to print desired pages. While three demand print- 
ing systems 62a-62c are illustrated in Fig. 3, it should be understood that the control unit 52 may operate a different 
number of demand printing systems, as desired. Also, the control unit 52 may operate a fax machine 64 and/or may 

35 communicate with other remote devices to send properly converted combined files, as desired and as noted above. In 
the case of other remote devices, a modem 65 may be operated by the control unit 52 to transmit data representing one 
or more pages to be displaced by a display device at a remote location over phone lines (land lines and/or cellular) or 
a combination of phone lines and the Internet. Alternatively or in addition, the data may be sent to a local or remote loca- 
tion at least in part over an intranet or another computer network through a direct connection therewith. The connbined 

40 files may be printed or may alternatively be reproducible in a different medium and/or may comprise a non-static image 
or other information, e.g.. movies or audio. 

The pages printed by the demand printing system 62 may be supplied to a finishing apparatus 66 which includes 
various auxiliary production devices and device interfaces for assembling the pages to produce finished books which 
are ready for distribution. The finishing apparatus 66 may include one or more gathering devices 70 for gathering 

43 printed pages into books, one or. more ink jet printers 72 for printing additional customized information, such as 
addressee information, on each book, one or more label printers 74 for printing address labels and/or other control 
devices 76. In addition, one or more detectors 78 may be provided to sense when a defective book is produced. The 
control unit 52 may be responsive to the output of the detector 78 to reorder a defective book at an appropriate point in 
the production sequence thereof so that advantage can be taken of postal discounts, if possible. 

50 One or more components of the finishing apparatus 66 may be physically located on the demand printer (i.e. 
"online finishing*^. Alternatively, the finishing apparatus 56 may be physically separate from the demand printer (i.e. 
"off line finishing"). 

Fig. 4 illustrates the demand print system 62a of Fig. 3 in greater detail, it being urderstood that the systems 62b 
and 62c are functionally similar. The system 62a includes a print system 79 having a press controller 80. a collator 81 
55 and a raster image processor (RIP) 82 which are operable in response to press commands generated by the control 
unit 52. A collator is an electronic device for storing raster image processor files (i.e.. bitmap files) and delivering 
selected files to a digital press in real time, such that the digital press can run at full speed while processing and printing 
unique page data for each book produced on the press. The RIP 82 converts the page files to bitmap format or any 



6 



EP 0 858 041 A2 



other format, such as a symbolic printer control language. The collator 81 includes menrtory in the form of mass storage 
drives and physical memory and collates the bitmap page files. If desired, the collator 81 and/or RIP 82 may comprise 
a part of the press controller 80. The controller 80 instructs the collator 81 to send page files to a demand printer 84. 
The print system 79 may comprise the PrintStreamer system, manufactured and marketed by Barco Graphics of Bel- 

5 gium. while the demand printer 84 may comprise the Xeikon DCP-1 digital color press noted above. Alternatively, the 
demand printer 84 may be a DocuPrint printer n^anufactured by Xerox Corporation and the RIP 82 may be a Xerox Doc- 
uf=*rint RIP. It should be noted that a different print system and/or demand printer may alternatively be used, such as the 
Indigo printer manufactured by Indigo NV. of Maastricht. Netherlands, if desired. 

Rg. 5 illustrates in diagrammatic generalized form the method of the present invention. For the purpose of explain- 

10 ing the present invention, as an.example. it will be assumed that the demand print system 62a will be operated to pro- 
duce a number of multiple-page books in the form of a brochure in duplex (or "saddle-stich") format. Figs. 6a and 6b 
illustrate tour pages Pi -P4 printed on a single sheet of paper .1 00 and4o be included in a brochure. The sheet of paper 
. 100 includes a first side 100a with printed pages PI . P4 thereon and a second side 100b with pages P2. P3 printed 
thereon. (As will become evident hereinafter, the use of designations P1-P4 is not meant to imply that such pages will 

15 necessarily become pages 1 . 2. 3 and 4 of the finished book.) In addition, pages Pi -P4 are inrtposed such that the page 
PT is placed on a right-hand portion lOOa-r of the side 100a while the page P4 is placed on a left-hand portion I00a-1 
of the side 100a. Further, the page P2 is placed on a left-hand portion 100b-1 of the side 100b while the page P3 is 
placed on a right-hand portion lOOb-r of the side 100b. In this fashion, when the sheet of paper 100 is folded along a 
fold line ,102 with the pages PI and P4 on the outside, the pages PI -P4 appear in sequence. (The format shown in Figs. 

20 6A and 6B is often referred to as "saddle stitch" imposition and is commonly used in magazines.) Because each book 
to be produced in this example includes multiple sheets of paper (or "forms'^, each folded once along a fold line, the 
imposition process takes into account shingling effects but not bottling effects. It should be noted both of that such 
effects will generally have to be taken into account when more than two pages are to be printed on a single side of a 
sheet of paper and thereafter foWed multiple times and assembled with other multiple-folded printed sheets of paper to 

25 create a book. 

In addition to the foregoing, in the first example, assume that the pages PI and P4 will become the outside front 
and back covers, respectively, of a finished book and include variable and fixed information thereon. Further, assume 
that the pages P2 and P3 will become the inside front and tjack covers, respectively, (as must be the case if PI and P4 
are the outside front covers) arxi include fixed information only thereon. For example, the page PI may include variable 

30 information in the form of a personalized message, a variable image, or the like in an area 1 10 whereas the page P4 
may include other variable information in an area 112, for example, postal information for mailing the brochure to an 

J addressee. Corresponding front and back pages of the remaining books may include differerrt variable information. The 
remaining printed information on pages P1-P4 may be identical to the printed information oh corresponding pages of 
remaining books. 

35 The books to be produced may include the same or differing number of forms and may have the same or differing 
numbers of pages. For example, the pages PI -P4 may be assembled with a number of other printed forms comprising 
twelve additional pages to produce a first book having sixteen pages. Another book to be produced in the same run may 
include some or all of pages PI -P4 and a second number of forms printed with twenty other pages, some of which may 
or may not be identical to the twelve additional pages of the first book. Filler pages may be placed in some or all books 

40 to cause such book(s) to have a certain number of pages. This may be necessary or desirable to result in a book length 
which is evenly divisible by four (in the event pages are imposed as two-page spreads) and/or to insure that particular 
page(s) appear on the left-hand or right-hand side in the finished book. 

In fact, the books to be produced in the same press run may be different in terms of page content and/or appear- 
ance, book length, book size (by changing page imposition parameters), book version, etc... Specifically, for example, 

45 the pages of Figs. 7a, 7b and 8a, 8b may be produced and assembled in different book versions together with the book 
version incorporating the pages of Figs. 6a and 6b in the same production run or job. Pages P5-P8 of Rgs. 7a and 7b 
are identical to the pages P1-P4, respectively, of Figs. 6a and 6b except that an additional area 1 13 is provided on the 
page P5 for placement of variable information, in addition to the areas 1 10 and 112. Because of the addition of the area 
113, the remaining master information appearing in an area 1 14 differs from master information appearing in an area 

50 116 of the page PI of Fig. 6a. 

The book version incorporating eight pages P9-P16 of Figs. 8a and 8b differs from the book versions incorporating 
the pages of Figs. 6a, 6b and 7a. 7b not only in terms of content of master and variable irrformation. but also number of 
pages and page size. Specifically, the pages P9. PI 2, P13 and PI 6 are to be printed on a first side 1 17a of a sheet of 
paper 118 and the remaining pages P10, P1 1, P14 and PI 5 are to be printed on a second side 117b of the sheet 118. 

55 In addition, the pages P1 1 -PI 4 are printed upside down relative to the remaining pages so that, when the sheet 118 is 
folded first along a fold line 1 19a and then along a fold line 1 19b. the resulting pages P9-P16 appear in order. Thereafr„ 
ter, the foWed sheet 1 18 is trimmed to separate the pages P9-P16- As should be evident, the pages P9-P16 are one- 
half the size of the pages P1-P8, and further include differerrt master and variable information thereon. The demand 
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printer may also have multi paper trays to select different paper sizes, stcx:ks, colors etc. or preprinted sheets to be 
included in the finished book. 

Referring again to Fig, 5. one or more template files 106 are developed by a publisher specifying the content 
(including appearance) of fixed information and the positioning of all information (i.e., fixed and variable) on the different 
books or book versions. A database 108 is also developed by the publisher using the personal computer 54 specifying 
the content of variable information to be placed in variable information areas, for exannple, the areas 110. 1 12 on the 
pages Pi. P4, respectively, of Figs. 6a and 6b. The database 108 further includes control information, as noted in 
greater detail hereinafter. 

The template files 106 include data specifying the position and content of fixed information on the pages to be 
printed. Specif icaliy, the template files 1 06 define template pages wherein each template page includes data represent- 
ing any fixed information to be reproduced on corresponding pages of the books or book versions and area data repre- 
senting any area(s) on the corresponding pages where variable information is to be reproduced. The tennplate files are 
duplicated to create working files. One set of working files is stripped of all area data relating to placement of variable 
Information to create stripped master page files 120 defining tenrplate pages having only fixed information thereon. The 
stripped master page files are then converted into PDL master page files 122 expressed in a page description lan- 
guage, such as PostScript®. 

Optionally, the PDL master page files 122 may be converted into two-page spreads by a page make-up program 
such as QuarkXPress®. Preferably, however, the PDL master page files 122 are provided to the print system 79 and 
imposed according to the imposition processes of the present invention, as explained in detail below. 

A further set of working files is stripped of all fixed information to create stripped variable page files 1 26 defining 
template pages having fixed information removed therefrom iand further having the area data defining the areas 110, 
1 1 2. The data representing template pages having variable information thereon are expanded into a set of intermediate 
page files. In the example of Figs. 6a and 6b and under the assumption that three books are to be printed, two interme- 
diate page files 130, 132 are thus produced- The file 130 includes a file portion PI -a defining the position of variable 
information to be produced on the page PI for the first book. Two other file portions P1-b and Pl-c define the position 
of variable information to be produced on the front outside covers of the remaining two books. In like fashion, file por- . 
tions P4-a. P4-b and P4-c represent the position of variable information to be reproduced on tiie back outside covers of 
the three books. At this point, data is also contained in each of the files 1 30, 1 32 identifying the entries in the database 
108 to be placed in the areas 110. 112 during printing. 

Thefiles130. 132 are then converted into variable page files 134, 136. The files 134. 136 are identical to the files 
130, 132, respectively, except that the data in each file identifying entries in the database are replaced by the actual 
data stored at such entries. The files 134, 136 are then converted into files 137, 138 in a PDL format, for example, Post- 
Script®. , 

Like the master PDL files 122, the variable PDL files 137, 138 may be^ converted into two-page spreads by a page 
make-up program such as QuarkXPress®. Preferably, however, the variable PDLfiies 137, 138 are provided to tiie print 
system 79 and imposed according to the imposition procedures of the present invention, as explained in detail below. 

The print system 79 operates in response to the press commands in a press command file 140 and merges the 
PDL master page files 122 with the PDL variable files 137, 138 to create the finished books or book versions. Alterna- 
tively, the master page files 122 may be premerged with the PDL variable files 137, 138 before the files are provided to 
the print system 79. 

Fig. 9 illustrates a flow chart of programming executed by the personal computer 54 for creating the template f ile(s) 
106 of Rg. 5. The programming may be written as an extension of QuarkXPress®, a page make-up program distributed 
by QuarK Inc. of Denver, Colorado. The QuarkXPress® program may be adapted for operation on the Apple® Macin- 
tosh® operating system or any other operating system, such as the Microsoft Windows® operating system. Alterna- 
tively, a different page make-up program may be used, if desired. 

During the make-up process for a document consisting of one or more pages, a template file is created for each 
book version to be produced, or, where a book is to include two or more parts (referred to as "sections" hereinafter) a 
template fHe may be created for each section. At a block 150 a user may select an area of a page for reproduction of 
variable information therein, at which point a line object, a text object or an image object may be selected. A block 152 
then checks to determine which type of object has been selected. If a text object has been selected, indicating that var- 
iable text is to be inserted at a point defined by the current cursor position on the computer display, the name or an indi- 
cation of the appropriate field in the database 108 is inserted into the tennplate file at tiie insertion point defined by the 
current cursor position by a block 154. If the user wishes to designate more areas; for variable information (block 156) 
control returns to the block 150 to await selection by the user. If the user then selects an image object, a box is defined 
by the user to contain an image at a desired location on a selected page. Control from the block 152 tinereafter passes 
to a block 1 58 which inserts a dummy picture file and an indication of the proper database field name in the template 
file for the page at the location indicated by the currerrt cursor position. The user will thereafter see the dummy picture 
file at the insertion point on the display of the computer 54 when the page is viewed. The dummy picture file will display 



8 



EP0 858 041 A2 



an indication of which database field will be used for insertion on the respective pages. 

Following the block 158. a block 160 prompts the user to enter an indication of whether the image object is to be 
displayed in one of several display formats. If the image is to be displayed in other than the original size thereof, a block 
1 62 sets a subname defined for the image to "fit," indicating that the image is to be scaled to fit the box. If the image is 
to be displayed in the original size thereof, a block 163 prompts a user to select a position for the image at a particular 
location in the box defined therefor, such as the upper left-hand corner, the lower right-hand corner, or the like. If the 
user does not select a position, the image is placed in the upper left corner of the image box. Control thereafter pro- 
ceeds to the block 156. 

If the block 1 52 determines that a line object has been selected, control returns directly to the block 1 50. inasmuch 
as variable information cannot be entered into a line object. The resulting page template files(s) are stored on a storage 
medium, such as an optical disc or other storage device, and/or thef iles(s) are downloaded together with the database 
to the control unit 52. 

At any point during the page make-up process, other functional aspects of the QuarkXPress® program may be 
invoked to both master and variable aspects as necessary to produce finished pages. 

The database 108 is assembled by creating an ASCII file having a plurality of records wherein each record includes 
one or more fields entered into the database in tab<lelimrted format (i.e, the fields are separated from one another in 
each record by tab keystrokes and the records are separated from one another by line returns) and wherein the fields 
are arranged under field names of a header. Each field may include text to be reproduced on a page or a name of an 
image file stored in the memory 53 and defining an image to be reproduced on a page. 

In addition to the foregoing data, the database 108 may include an optional field designating the number of copies 
of each book to be produced, an optional townsort image field, a version identification field indicating book version 
number if multiple book versions are to be produced, an optional distribution list field, control data and the like. 

A sample database is set out below having a header consisting of twelve fields (i.e., "version,** '*addressline1 
"addressline2," etc.) and a number of records, nine of which are shown, each having twelve fields: 
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In the example of Figs. 6a and 6b. the field names ADDRESSL1NE1 through ADDRESSLINE5. BARCODE and 
TOWNSORT may appear in the area 112 and one or more of the field names PRICE1, IMAGE1 AND PRICE2 may 
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appear in the area 1 10. The COPIES field may be used as a control code to select the number of book copies to be 
produced. 

Once the template f ile(s) 1 06 and the database 1 08 are assembled, the programming of Figs. 1 0a- 1 0f may be exe- 
cuted by the control unit 52 to create the master page file 122, the final variable page files 137 and 138. and the press 
5 command file 1 40. Refemng first to Fig. 1 0a. a block 1 70 prompts a user to select a template file 1 06 and a block 1 72 
opens the database 1 08. A block 174 then reads and stores in a list the database field names for later reference and a 
block 176 prompts a user to enter information indicating a section number and whether pages are to be printed in sim- 
plex (i.e., single-sided) or duplex (i.e.. double-sided) format. The section number identifies the order in which multiple 
sections are to be processed for a particular book. The user may also be prompted to enter a selective processing code 
10 identifying a particular book version to process if nujltiple versions are to be produced during a single press run. 

Following the block 176, a block 177 begins the process of stripping variable information from the tenplate file 
opened by the block 1 70 to obtain the stripped niasterifile 120 of Fig. 5. The block 1 77 selects a first page tor processing 
and a block 178 checks to determine whether there are any images in the template file and, if images are located, a 
block 180 selects a first image. 
15 A block 182 identifies the file name for the image and a block 1 84 checks the field list to determine whether the file 
nanne is included therein. If the file name for the image is included in the field list, then the image comprises variable 
information and a block 186 deletes the image block. A block 187 then identifies and saves the image box location on 
the page, the characteristics of the image box, such as the size, skew, background color and subname and the like and 
further saves the field name of the image from the database T08. Also, a counter in the memory 53 which tracks the 
20 number of variable image boxes on the page is incremented. 

Othenwise. if the block 1 84 determines that the file name is not in the field list, then the image contains only master 
information. A block 188 then also saves the image box location on the page and the characteristics of the image box. 
Also, a counter in the memory 53 which tracks the number of master image boxes on the page is incremented. 

A block 1 89 then checks to determine whether all images have been processed. If not. a block 190 selects a next 
25 image and control returns to the blocks 182-189, Control remains with such blocks until the block 189 determines that 
all images have been processed and control then passes to a block 192. Control also passes to the block 192 from the 
block 178 should the latter determine that there are no images in the template file. 

The block 192 determines whether any text boxes are present in the open template file. If at least one text box is 
present, a block 1 94 selects and parses a first text box and a block 1 96 (Rg. 1 0b) checks to determine whether the text 
30 box includes at least one of the field names of the database 108. If so, then it has been determined that the text box 
includes variable information and a block 198 deletes the text box. A block 199 then stores the text box location, the 
insertion points in the text box at which variable information is to be printed and the characteristics of the text box and 
the field names of the database 1 08 identified in such text box in the memory 53. In addition, a variable text box counter 
is incremented representing the number of variable text boxes appearing on each page. 
35 Othenvise, if the block 196 determines that the text box does not include any field names from the database, then 
the text box contains only master information. A block 200 stores the text box location in the memory 53. In addition, a 
master text box counter is incremented representing the number of master text boxes appearing on each page. 

Control then passes to a block 202, which checks to determine whether all text boxes in the template file have been 
processed. If not, a block 204 selects and parses the next text box in the template tile and control returns to the blocks 
40 ^ 96-202. Control remains with such blocks until all text boxes have been processed, whereupon a block 206 determines 
whether all pages have been processed. If not. a block 208 selects a next page and control returns to the block 178 
(Fig. 10a). Otherwise, a block 210 saves the resulting file as the stripped master file. 

Alternatively, if a page contains a lot of formatting information (i.e. tabs, fonts, etc.), a rich text file (which includes 
such formatting information) may be created offline from the database. The text box may then open the rich text file and 
45 read the information from the file. The use of the rich text file speeds up the processing time. 

Also, once a placeholder on a page has been "filled in" with information from the database field, the program may 
mark the corresponding text or image box as "touched." Thus, if the text or image box is "untouched," the program can 
skip processing of that text or image box, also speeding up the total processing time. 

Control also bypasses the blocks 1 94-202 and proceeds directly from the block 1 92 to the block 206 if the block 1 92 
50 determines that there are no text boxes in the open template file. 

Following the block 210. a block 212 converts the stripped master file into the PDL master page file 122 of Fig. 5. 
At the same time, an initialization (or INI) file may be created. The format and existence of the INI file depends on the 
type of demand printer utilized. For example, the DocuPrint demand printer does not require the use of an INI file. How- 
ever, the Barco RIP requires the use of an INI file. 
55 The INI file (in ASCII code) for the Barco RIP is created according to the following format: 

name: [file path\name] 

psx: [dimension] 
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10 



15 



psy: 

55x: 

ssy: 

posx: 

posy: 

duplex: 

orientation: 

output: 

copies: 



[dimension] 

[dimension] 

[dimension] 

[dimension] 

[dimension] 

[zero or one] 

[zero or one] 

[filename] 

[number] 



Where "psx" and "psy" refer to finished page sizes in x and y directions, "ssx" and "ssy" refer to cut sheet size in x and 
y directions, "posx" and "posy" refer to offsets in x and y directions specifying placement of each page on a cut sheet, 
"duplex" refers to single or two-sided printing, "orientation" refers to portrait or landscape printing, "output" refers to the 
name of the output file and "copies" refers to the number of copies to be printed. A sample INI file which specifies 
parameters for printing of a file called MYJOB.PS is as follows: 



20 



25 



Name: 


C:\jobs\myjob.ps 


psx: 


8000 


psy: 


11000 


ssx: 


11500 


ssy: 


9000 


posx: 


150 


posy: 


150 


duplex: 


1 


orientation: 


1 


output: 


myjob.ps 


copies: 


1 



30 



35 



40 



In the foregoing example, one copy of the file MYJOB.PS is to be printed in duplex and portrait formats at an offset of 
0.15x0.15 inches from a corner of a finished sheet of paper 8x11 inches cut from a sheet originally having dimensions 
of 9 X 1 1 .5 inches. 

For the DocuPrint (or any other demand printer which does not use anINI file), a queue is aeated which contains 
the same parameters (and potentially additional parameters which may invoke the functionality of an in-line finisher, or 
other apparatus) as the INI file. 

Following the block 212. a block 214 then reopens the same template file originally opened by the block 170 and 
deletes all the master image and text boxes. A block 21 6 than saves the resulting file as the stripped variable file 1 26 of 
Fig. 5. 

A block 21 8 then creates a temporary file containing a table of the current page number and a number representing 
the name of the database field placed by the block 154 at the insertion point. The file Is called, for example. '.VARS 
(where * is a user-selected file name). The ".VARS file thus contains pairs of page nunnbersand database column num- 
bers chat indicate where in the database variable information for the page comes from. For example, the *.VARS file 
may contain the following information: 



1 


7 


8 


43 


9 


44 


10 


45 


11 


46 


11 


47 


13 


50 


14 


52 


15 


50 


15 


51 



55 In the example above, page 1 contains variable data from column 7 of the database, page 8 contains variable data from 
column 43 and page 11 contains variable data from column 46 and 47. Further, the '.VARS file may contain separate 
pairings for images and text. 

Control then passes to block 242 (Fig. 10c) which creates a working copy of the stripped variable file 126. A first 
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page having variable data thereon is selected and data representing the renrtaining pages in the file are deleted by a 
block 244. In the exanople of Figs. 6a and 6b, the block 244 creates a file defining the front cover of a book with all fixed 
infornnation deleted therefrom and an area reserved for variable information. 

Following the block 244, a block 246 selects a first record in the database 108 and a block 248 reads the record. 
5 An optional block 250 checks to determine whether a selective processing code has been entered by the user indicating 
that the page is to undergo selective page processing. As noted above, the apparatus and method of the present inven- 
tion may be utilized to produce not only tx)oks of a single version (i.e., where corresponding pages differ only in terms 
of the variable information stored in the database) but also books of different versions. In the latter case, the books of 
different versions have different fixed and variable information. The fixed and/or variable information may vary in temns 
10 of content or appearance (i.e., style, location, rotation, position, etc.) or both in different versions. 

If the block 250 determines that selective page processing is to be undertaken, then a block 252 checks to deter- 
mine whether the database record read by the block 248 is to be utilized on the page currently under consideration. The 
block 252 accomplishes this by checking the version identification field in the database to determine if that version is 
being used. If this is not the case, a block 253 checks to determine whether the record currently under consideration is 
15 the last in the database. If so. control passes to a block 294 of Fig. 1 0e. Otherwise, a block 254 selects a next record in 
the database 108 and control returns to the block 248 where the next database record is read. 

If the block 250 determines that selective page processing is not to be undertaken, or if the block 252 determines 
that the record read by the block 248 is to be used in the page currently under consideration, a block 256 duplicates the 
data representing the page remaining after execution by the block 244 to initiate development of one of the files 130 or 
20 132. In the first pass through the program of Fig. 10c, and in connection with the example of Figs. 6a and 6b, the block 
256 creates the file 130 and develops page data representing a first version of the page PI -a and adds further variable 
information to such page data during immediately succeeding passes through the program. Thereafter, data represent- 
ing the remaining pages PI -b, PI -c and P4-a through P4-c are created and variable information is added to such pages 
serially during subsequent passes. 
25 A block 258 checks to determine whether there are any image boxes on the page and. if so, a block 260 selects a 
first image box. A block 262 then inserts the image identified by the database field into the image box. A block 264. Fig. 
1 0d. checks the subname to determine whether the block 1 62 of Fig. 9 has indicated that the image should be sized to 
fit the image box. If this is true, a block 266 performs the scaling. Otherwise, a block 268 positions the image in the 
image box at the position specified by the user and a block 270 checks to determine whether all image boxes have been 
30 processed. Control also passes from the block 266 directly to the block 270. thereby skipping the block 268. If not all 
image boxes have been processed, a block 272 selects a next image box on the page and control returns to the blocks. 
262-270 so that remaining image boxes are serially processed. 

Once the block 270 determines that all image boxes have been processed, or immediately following the block 258 
of Rg. 10c if no image boxes are found on the page, a block 274 checks to determine whether there are any text boxes 
35 on the page and, if so, a pair of blocks 276, 278 select a first text box and a first insertion point in such box. Blocks 280, 
282 and 284 serially insert text data stored in the database 1 08 at the appropriate insertion points in the text box. Once 
all of the variable text data have been inserted into the text box, a block 286 recomposes all text in the text box so that 
the text obtains a neat finished appearance. The recomposition process is automatically undertaken by the QuarkX- 
Press® program once the variable information is inserted into each text box. The recomposition process is responsive 
40 to the user commands as applied to the template file text box or object, such as left, right, center, or full justification, 
hyphenation and the like. Following the block 286, a block 288, Fig. lOe, checks to determine whether there are remain- 
ing text boxes to be processed on the page and, if so, a block 290 selects the next text box on the page and control 
returns to the blocks 278-288 to insert text information into such text boxes. 

Once the block 288 determines that all text boxes for the page have been processed, the programming required to 
45 produce one of the pages of the file 1 34 of Fig. 5 having variable information only thereon is complete. A block 292 then 
determines whether all records in the database have been considered for inclusion in additional variable pages of the 
file 134 to be produced. If not all records have been considered, control returns to the block 254, Fig. 10c, where the 
next database record is identified and read. On the other hand, if all pages of the file 134 have been produced by con- 
sidering all records in the database 108, a block 294 converts the file data into PostScript® or another PDL format to 
50 create the variable page file 137 of Fig. 5. Also, an INI file is created as before, except that the "duplex" or "twinplex" 
parameter is set to command simplex printing only. If necessary or desirable, should the press run length exceed a cer- 
tain limit, the programming may be modified to create more than one variable page file for each variable page of the 
template file. 

Following the block 294. a block 296 checks to determine whether there are other variable pages in the stripped 
55 variable page file to be processed. If this is true, a block 298 retrieves a copy of the stripped variable file, selects the 
next variable page therein and deletes remaining pages therefrom. Control then returns to the block 246 of Fig. 1 0c. In 
the example of Figs. 6a and 6b, the back cover P4 and the corresponding pages of the remaining books are now 
selected for processing. In the fashion noted above, a file representing the variable portions of such pages is produced 
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by developing the file representing the pages P4-a through P4-c and inserting the database information into such file to 
obtain the variable page file 136 and the PDL version 138. 

Following generation of the variable page files 134, 136, and 137. 138 control passes to a block 300 which checks 
to determine whether a press command file has already been created. If not, a file is created by a block 302 having 
placeholder comments indicating where in the press command file individual press commards are to be placed for each 
book to be produced. The press command file may also include data from one or more fields of the database 1 08 iden- 
tifying an intended recipient of each book to be produced to assist in reproducing books four>d to be defective or to pro- 
duce sample books. At this point, the press command file for the example of Figs. 6a and 6b may be as follows (using 
data from the sample database set out above): 

:RECORD1 

;:WILLIAM DOE:606248923 
;ENDRECORD 
, :RECORD2 
::HUGH JORGENSEN:606248923 
;END RECORD 
:RECORD3 

;:JAY P. MORGAN:606248924 
;END RECORD 

Following the block 300 (if the press command file already exists) or the block 302 a block 304 selects the first data- 
base record and a corresponding first record in the press command file. A block 306 then checks to determine whether 
the template file currently being processed includes the selected database record. If not, a block 308 determines 
whether all pages have been processed, and if this is nor the case, the next record in the database 108 and a corre- 
sponding record in the press command file are selected. Control then returns to the block 306. If the block 306 ascer- 
tains that the template file includes the selected record, a block 312 inserts an Indication of the section number in the 
press command file at an appropriate point if the section number is not already present. If the section number is present 
already, the press command identified by the section number entered by the user at the block 176 is identified to be 
ovenwritten at a later point. The press command file now appears as follows for the example of Figs. 6a and 6b: 

;REC0RD1 

;:WILL1AM DOE:606248923 
iSECTION 1 
;ENDSECTION 
:ENDRECORD 
;REC0RD2 

;:HUGH JORGENSEN:6062488923 

;SECTION 1 

;ENDSECTION 

;END RECORD 

;RECORD3 

;:JAY R MORGAN:605248924 
:SECTION 1 
;END SECTION 

;END RECORD ^ 

Following the block 312, a block 314, Fig. lOf, selects a first page of the section and a block 316 checks the state 
of a flag stored in the memory 53 to determine whether a simplex or duplex job has been requested. If a simplex job 
has been requested, the file name and page number of the master page file and, if variable information is to appear on 
the page, the file name and page number of the variable pageJile for the selected page are stored as a single set pair 
in the memory 53 by a block 318. The determination of whether variable information is to appear on the selected page 
is accomplished by summing the contents of the variable image box counter and the variable text box counter as incre- 
mented by the blocks 220 and 234 of Fig. 10b. 

A block 320 checks to determine whether all pages have been processed and. if not. the next page is selected by 
a block 322 and control returns to the block 316 for processing of such page. If all pages have been processed, control 
passes to a block 324 which determines whether all database and press command records have been processed. Con- 
trol also passes to the block 324 if the block 308 determines that all pages have been processed. If not all records have 
been processed at this point, control returns to the block 310 where the next records in the database and press com- 
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mand file are selected. 

If the block 324 determines that all records for the current section have been processed, a block 326 determines 
whether another section is to be processed and, if so, control returns to the block 1 70 of Rg. 1 0a. If there is not another 
section to be processed, the press command file has been fully assembled, and hence the process terminates. 

If the block 316 determines that a duplex job is to be effected, control passes to a block 328 which stores in the 
memory 53 a command identifying the file names and page numbers of the master page file (as well as corresponding 
information relative to variable page files, if variable information is to appear) as two-set pairs. Control from the block 
328 then passes to the block 320 described above. 

The result of the programming of Figs. 10a-10f is a press command file having a sequence of press commands 
which cause printing of pages in a desired order. In order to print the sample pages of Rgs. 6a and 6b, the press com- 
mand file would read as follows: 



BOOK A 

;REC0RD1 

;:WILUAM DOE:606248923. 
:SECT10N 1 

Tile.m''1@1ile.vrirfiie.m''2 

1ile.m''3rfile.m''4@*1ile.v4"1 

;ENDSECTION 

;ENDRECORD 

;RECORD2 

::HUGH JORGENSEN:606248923 
:SEGT10N 1 

•^f ile.m"1 @"f ile.vl "2rf ile.m-2 

^ile.m"3rfile.m"4@1ile.v4''2 

:ENDSECT10N 

;ENDRECORD 

; RECORDS 

; JAY R MORGAN :606248924 
. ;SECT10N 1 
"file.m''1@Tile.vr3rfile.m''2 
^ile.m''3rfile.m"4@"file.v4"3 
:ENDSECTION 
;ENDRECORD 
ENDBOOK 
PRINTRUN R 
BOOK A 
ENDPRINTRUN 



In the foregoing example, lile.m" is a file name identifying the master page file 122 and "file-vl " and **fiie.v4" are 
file names identifying the variable page files 1 37 and 138, respectively. The number following each file name designates 
a particular page of the file identified by the file name. Thus, for exanple. "f ile.m"! designates the first page of the mas- 
ter file *^ile.m" and '1ile.v1"2 designates the second page of the variable page file ''file.vl." The @ sign means to asso- 
ciate the pages of the files linked by such sign (i.e. overlay the variable pages on the master pages). The vertical line in 
the commands indicates that the page(s) on the left side of the vertical line are to be printed on the front side of a piece 
of paper whereas the page(s) on the right side of the vertical line are to be printed on the reverse side of the piece of 
paper. In an example of simplex printing, no file name would appear to the right of the vertical line in each command. 

Fig. 1 1 illustrates the programming implemented by the control unit 52 to generate a page description language 
instruction set specifying which pages should be printed and how the pages should be positioned (or imposed) for print- 
ing. The page description language instruction set may be incorporated into the press command file 1 40 or may be pro- 
vided as a separate file to the print system 79. For purposes of illustration, the page description language instruction 
set is written in PostSaipt® in the format dictated by the Xerox DocuPrint printer. Further, the instruction set is directed 
to books printed in "saddle stitch" imposition format (i.e. 2 pages on each side of sheet) as explained in connection with 
Figs. 6-8. It is understood, however, that the invention could easily be modified for use with a different demand printer 
(i.e. the Xeikon Barco printer) and/or imposition format (i.e. 4 pages on each side of sheet). 

Referring to Fig. 1 1. the programming begins at a block 340 which prompts a user to specify certain information to 
be used to paginate the book. A variable ("MAXPGS") representing the maximum number of supplied pages that may 
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or may not be assembled into a single book during the job is specified together with the identification of filler page(s) 
that may or may not be printed and assembled at the end of a book either on a left-hand or a right-hand portion thereof. 
Also, the user is prompted to specify for each page whethei- such page will be forced to be on the left side of a book, 
the right side of a tx>ok or will not be forced to a particular book side. In the event a page is to be forced to a side, the 
5 user is prompted to specify the page file name and page number for a filler page to precede the forced page. Still fur- 
ther, the user is prompted to specify for each page whether such page is: 

1) A Master Page ■ contains the same information and is included in every book; 

2) An Always Variable Page - may contain variable information and is included in every book; or 

10 3) A Selectively Variable Page • contains variable information and is selectively included in certain books. 

- In so specifying the foregoing, the user aeates a pagination file (called, for example, *.PAG, where * indicates a file 
name selected by the user). A sample window generated by the block 340 to prompt a user for the information needed 
to create the pagination file is shown in Fig. 1 2. 
15 Referring again to Rg. 11, following the block 340, a block 342 opens the press command file 140 and a block 344 
selects the appropriate database files, including the variable information file (*.VARS), the pagination file (*.PAG), and 
(optionally) a barcode file. As set forth above, the *.VARS file is a temporary file of pairs of page numbers and database 
column numbers that indicate where in the database variable information for the page comes from. 

The barcode file is a page description language file (for example, a PostScript® file) whtch contains instructions for 
20 printing the sequential page numbers and/or a tracking bar code on the pages of the completed book. The barcode file 
will be explained in detail betow. 

The programming then proceeds to the loop containing blocks 346, 348, 350, 352 and 354. The block 346 takes 
each record (or book) in the press command file 140 in sequential order. For each record, the block 348 determines 
which pages should be printed to generate that particular book. Next, the block 350 determines whether the pages to 
25 be printed should be forced to the right hand or left hand side of the book and the block 352 "pads" the pages to be 
printed to be a multiples of the number of pages to be printed on a sheet (in our example. 4) by adding appropriate filler 
pages. Next, the block 354 generates the PostScript® instruction set and the programming returns to the block 346 to 
retrieve the next record in the press command file 140. The loop repeats for each record in the press command file 140. 
Fig. 1 3 illustrates in detail the programming steps implemented by the block 348 of Fig. 1 1 , which determines which 
30 pages should be printed for a particular record in the press command file 140. A block 360 first retrieves the first page 
in the record, A decision-making block 362 then determines whether the page is from a new file chat is to be "imposed- 
on-the-fly with offsets." (Imposition-on-the-fly with offsets is one of the imposition formats of the present inverrtion, 
which will be explained in detail below). If yes, a block 364 calculates and saves the offsets for alt the pages in the file. 
After the block 364 calculates and saves the offsets or if the block 362 is false, a decision-making block 366 then deter- 
35 mines whether the page is a master page (i.e. does not include any variable information placeholders). If the page is a 
master page, the page should always be printed and a block 368 "marks" the page to be printed. The block 368 may 
"mark" the page by adding it to a page print array. The page print array contains the page number and a marker to indi- 
cate the disposition of the page. For example, pages that should not be printed are designated with a "0"; master pages 
(always printed) are designated with a "1 "; and variable pages to be printed are designated with a "2". 
40 If the block 366 determines that the page is not a master page (i.e. it's a variable page), a decision-making block 
370 determines whether the variable page should be printed at all times. (This was designated by the user at the block 
340 in Fig. 1 1 during creation of the pagination file). If yes, the block 368 marks the page to be printed. If no, a decision- 
making block 372 determines whether the page has any variable placeholders with valid data. In other words, the block 
372 determines whether there is any variable information from the database to be printed on the page. If yes, the block 
45 368 marks the page for printing. The program then returns to the block 360 to retrieve the next page from tine record 
until all the appropriate pages have been marked for printing. 

Fig. 14 illustrates in detail the programming steps implemented by the block 350 of Fig. 11 to determine whether 
the pages should be forced to the left or right hand side of the book. A block 380 first initializes a left/right {U9) counter 
variable to its default value of right because it is assumed that the first page of the book will be one the right side. Next, 
so a block 382 retrieves the first page from the record tiiat is marked "should print" and a block 384 determines whether 
the user has specified whether the page should be forced to the left or right side. (This was designated by the user dur- 
ing creation of the pagination file at block 340 of Fig. 1 1). If the user has not specified that the page should be forced, 
a block 386 flip-flops the L/R counter such that if it was set to right it is changed to left and if it was set to left, it is 
changed to right and the program returns to tiie block 382 to retrieve the next "should print" page in the record. 
55 Alternatively if the block 384 determines that the user has specified that the page should be forced left or right, a 
block 388 determines whetiier the user specification matches the orientation of the page (i.e. is it the same as tiie UR 
counter). If yes, the block 386 flip-flops the UH counter and returns to the block 382 to retrieve the next "should print" 
page in the record. Otherwise, a block 390 marks an appropriate filler page (which was identified by the user during cre- 
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ation of the pagination file) to be printed and the program returns to the blodK 382 to retrieve the next "should print" page 
in the record. 

Fig. 15 illustrates in detail the programming steps implemented by the block 352 of Rg. 1 1 to "pad" the pages into 
a multiple of the number of pages to be printed on a sheet. In our example, using "saddle stitch" imposition, four pages 
are printed on a sheet (2 pages per side). Therefore, filler pages may need to be added to ensure that the total number 
of pages in the book is a multiple of 4. A block 392 first counts the number of pages in the record that have been marked 
to print. This includes alt the master and variable pages that were marked by the block 368 of Rg. 1 3 as well as any filler 
pages that were marked by the block 390 of Fig. 14. Next, a block 394 determines whether the total number of pages 
IS a multiple of 4. If not, a block 396 adds the appropriate number of filler pages to make the total number of pages a 
multiple of 4. For example, if the block 392 determines that 18 pages are marked to print, the block 396 will add 2 filler 
pages to make the total nunnber of pages in the book equal to 20 (a multiple of four). The program then returns to the 
block 354 of Fig. 1 1 which generates the PostScript® instruction set. 

The PostScript® instruction set specifies how the pages marked to print should be positioned (or imposed) for print- 
ing. In our example, for a "saddle-stitch" imposition format, and assuming a 12 page book, the block 354 generates an 
instruction specifying that the pages should be positioned as shown in the following tabJe: 



Sheet No. 


Side No. 


Left Side 


Right Side 


1 


1 


Page 12 


Page 1 


1 


2 


Page 2 


Page 1 1 


2 


1 


Page 10 


Page 3 


2 


2 


Page 4 


Page 9 


3 


1 


Page 8 


Page 5 


3 


2 


Page 6 


Page 7 



It is understood that a different instruction set could be generated (by an imposition program) to irrpose and print the 
pages in a different format (i.e. four pages per side) or alternatively, a different number of total pages. 

After the block 354 generates the imposition instruction set, the pages are imposed and printed according to an 
imposition procedure of the present invention. The first imposition procedure of the present invention utilizes an artificial 
PostScript® operator called "GetTIFF". which is recognized by the Xerox DocuPrint RIP. wherein page files are preproc- 
essed to TIFF ("tagged image file format") format before being provided to the RIP The second imposition procedure 
of the presient invention (referred to as "imposition-on-the-fly") involves downloading imposition programs to the RIP 
which redefine various PostScript® operators to automatically position pages while each page is being interpreted. 

A user is prompted to specify various information needed for imposition and printing, including the sheet size (i.e. 
1 1x1 7), imposition style (Imposition-on-the-fly or GetTIFF), finishing style (online or offline), the output device (i.e. Xerox 
DocuPrint or Barco Xeikon) and the name of the directory where the master and variable page files are stored. A sam- 
ple window to prompt a user to provide this information is shown in Fig. 16. 

GetTIFF Imposition 



A TIFF (tagged image file fornr>at) file is a bitmap representation of a page in the same screen format as the print 
engine. Several commercially available RIPs (such as Image Alchemy PS or TranverterPro) process pages represented 
in a page description language format to TIFF format. The Xerox DocuPrint RIP recognizes an artificial PostScript® 
operator called "GetTIFF" which retrieves a specified TIFF file and quickly processes the file lor rendering by the Doc- 
uPrint demand printer (Other demand printer RIPs. including the Barco Xeikon. may also be modified to recognize a 
GetTIFF-type operator). 

In a prefen-ed embodiment of the present invention, the master page PDL files 1 22 and the variable page PDL files 
1 37. 1 38 are preprocessed to TIFF format. Because the Xerox DocuPrint system allows for only one input data stream 
(as opposed to the Barco Xeikon system which allows two data streams - master and variable), the master page PDL 
files 122 and the variable page PDL files 137, 138 may be premerged. This may be acconrpiished by forcing all of the 
master data onto the variable template files. After the master and variable pages are merged, the instruction set and 
GetTIFF operator are used to quickly impose and process the pages for printing. 

Alternatively, the master and variable data streams may be overlayed by first processing the master pages and then 
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overlaying the variable pages onto the master pages. 

Fig. 17 Illustrates programming which may be executed to facilitate conversion of the page files into TIFF format. 
The programming begins at a block 397 which opens the press command file stored in the memory 53. A block 398 then 
prompts a user to specify options which are available. The options include the ability to convert only master page files, 
5 only variable page files or both master and variable page files into bitmap format. A block 399 then selects the first line 
in the press command file having at least one file name therein. Thereafter, a block 400 selects a first file name and a 
block 401 checks a file list stored in the memory 53 to see if the file name has been previously placed. in the list If this 
is not the case, then this is the first time the file name has been encountered In the programming of Fig. 17. Thus, a 
block 402 adds the file name to the file list and a block 403 checks the user-specified options set by the block 398 to 
10 determine whether the file should be converted into TIFF format. If so, a RIP list stored in the memory 53 is updated by 
adding the file name thereto (block 404) and control passes to a block 405. Control also passes to the block 405 from 
the block 403 (bypassing the block 404) if the file is not to be converted into TIFF format, and from the block 401 if the 
file name currently under consideration is already in the file list. 

The block 405 checks to determine whether the end of the cuaent line in the press command file has been reached. 
75 If not, a block 406 selects the next file name in the line and control returns to the block 401 . 

If the block 405 determines that the end of the current line in the press command file has been reached, a block 
407 checks to determine whether the end of the press command file has been reached. If not. a block 408 selects the 
next line in the press command file having at least one file name and control returns to the block 400. On the other hand, 
if the end of the file has been reached, a block 409 causes the RIP 82 (or another RIP) to convert the files identHied in 
20 the RIP list into TIFF format. 

The programming of Fig. 1 7 thus facilitates conversion of files to TIFF format as required by the print system 79. 
Referring to Hg. 1 8. if the user specified GetTIFF imposition and after the page files have been RIPped to TIFF for- 
mat by the programming of Rg. 1 7. a block 410 retrieves the first page pairing from the instruction set (in our example, 
page 12 as the left hand page and page 1 as the right hand page), A block 412 then retrieves a reference to the page 
25 description of the left hand page in TIFF format from the page file and provides it to the RIP 82. Assuming the default 
offset is positioned at the left side of the sheet, the left hand page is positioned on the left side of the sheet. 

A block 414 then moves the offset to position the next page onto the right side of the sheet. A block 416 retrieves 
the reference to the page description in TIFF format of the right hand page from the page file and provides rt to the RIP 
82. Next, a block 41 8 may add page numbers and/or a bar tracking code to the sheet, as explained below. The program 
30 then returns to the block 410 to retrieve the next page pair from the instruction set and the program repeats until all 
pages and all books have been processed. 

After all pages have been processed, they are RIPped and printed by the demand printer 84 in accordance with the 
initialization (INI) file, which was created by the block 212 (Fig. 10b). 

If, for example, the demand printer is a DocuPrint (i.e., no INI file was created), the pages are submitted to the 
35 queue (which contains the same parameters as the INI file) for RlPping and printing. 

A partial PostScript® instruction set for printing the 12-twelve page brochure in accordance with the table above 
implementing the GetTIFF imposition according to Fig. 18 is set forth below: 



40 
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<< 

/PageSize [1224 792] % sec sheen size 

>> secpagedevice % (11 x 17) 

{VERONi2.voi_dir/ % get lefc page 

VER0N12 . VOl . 00000002 . tiff) GetTIFF 

612 0 cranslane V move co right 

(V£RON01.V0l_dir/ % gee right page 

VERONOl . VOl , 00 000002 . tiff) GetTIFF 

showpage 

(VERON02.M_dir/ V get left page 

VERON02 .M. 00000002 . tiff) GetTIFF 

612 0 translate % move to right 

{VERONll.V0l_dir/ % get right page 

VERONll. VOl. 00000002 . tiff) GetTIFF 

showpage 



(VERON06,M_dir/ % get left page 

VERON06,M-00000004-tiff ) GetTiff 

612 0 translate % move to right 

(VERON07.V03_dir/ V get right page 

VERON07 . V03 . 00000003 . tiff) GetTiff 

showpage % reset to left 



In the instruction set. the "VERON*.*_dir/VERON*,*" indicates the directory and filename where the page descrip- 
tions are located. The suffix ".M" indicates a master page and the suffix V " indicates a variable page (with the ver- 
sion number of the variable page to be printed). The suffix " .tiff is the file name created by the RIP which 

converted the page files to TIFF files and indicates that the files are in TIFF format. The artificial PostScript® "GetTIFF'' 
operator interprets the TIFF files. The "612 0 translate" command moves the offset to the right hand side of the sheet 
(block 414) and the PostScript® showpage operator transmits the page to the demand printer 84 for rendering, pre- 
pares for interpreting the next page description and resets the offset to the left hand side. 

Optionally, the block 41 8 may print page numbers and/or a bar tracking code onto the sheets printed by the demand 
printer 84. This may be accomplished by adding the following additional PostScript® code before the showpage oper- 
ator in the instruction set shown above: 



/C39P24Dm 24 selectfont 
30 4.5 sub 18 translate 90 rotate 
0 0 moveto 
(1.12) show 

/Helvetica 12 selectfont 
320 780 moveto 
(12) show 
-320 780 moveto 
(1) show 



% add bar code info 

% position on 

% side of sheet 

% indicates sheet 1 of 12 

% 

% add page numbers 

% center in middle of left page 

% print page "1 2" 

% center in middle of right page 

% print page "1 " 



The first section of code provides the command for printing a bar code (indicating for example, the page number and 
the total nunnber of pages in the book). The second section of the code prints page numbers centered at the bottom of 
each page. A similar technique could be used to do any "post page" modifications, such as watermarking samples or 
QC books, adding variable printers marks or the like. 
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Imposition-on-the-nY 

The user may also specify that the pages be imposed and printed using the imposition-on-the-fly technique of the 
present invention. This technique positions the pages whiie the pages are being interpreted by the RIR Fig. 1 9 is a more 
detailed block diagram of the print system 79 shown in Fig. 4, The PDL master page files 122 and the PDL variable 
page files 137, 138 may be combined into merged PDL files (such as merged PostScript file(s) 450), which are then 
provided to the print system 79, comprised of RIP 82, collator 81 , press controller 80 and demand printer 84. The press 
command file 140. which includes the instruction set for specifying how pages should be imposed, is also provided to 
the print system 79. 

Alternatively as described above, the master page files 122 and the variable page files 137, 138 may be provided 
separately to the print system 79 and overlayed. 

The print system 79 may also include a raster memory 452 associated with the RIP 82 and the demand printer 84. 
The RIP 82 generates a raster description of the "current page" being interpreted, which may be stored in the raster 
memory 452 or provided to the demand printer 84 for rendering. The demand printer 84 physically renders pages 454 
from the merged PostScript® file 450 onto a "flat" (or other medium) 456. 

For purposes of illustration, it is assumed that the RIP 82 interprets the widely used PostScript® PDL language. 
(PostScript® is a registered trademark of Adobe Systems. Inc.) The PostScript® language Is fully described in the 
PostScript® Language Reference Manual, Second Edition (1990), from Adobe Systems, Inc., which is incorporated 
herein by reference. Certain imposition-on-the-fly procedures 454 according to the present invention are downloaded 
to the RIP 82. (The procedures 454 include, for example, ImposeJob, ImposeFile and various redefined PostScript® 
operators which are described in detail below). The imposition-on-the-fly procedures 454 wilt be used by the RIP 82 to 
process the instruction set and the page descriptions contained in the merged PostScript® files 450 to efficiently trans- 
mit pages for rendering by the demand printer 84. (For ease in illustration, it is assumed the master and variable page 
files were premerged into merged file 450. It is understood, however, that the master and variable page files could also 
be overlayed.) 

PostScript® Background 

In order to facilitate the explanation of imposition-on-the-fly procedures of the present invention, some background 
regarding the PostScript® language is provided. Further background details may be found in the PostScript® Lan- 
guage Reference Manual, Second Edition (1990), from Adobe Systems. Inc., which was previously incorporated by ref- 
erence. 

The RIP 82 manages four different stacks, which are "last-in-first-cut" (UFO) data structures. These stacks include: 

(1) an Operands Stack which holds (i) the input operands to various PostScript® operators, and (ii) the results of 
the operations, 

(2) an Execution Stack which is controlled by the RIP 82 and which holds executable objects (i.e. procedures and 
files) that are in stages of execution; 

(3) a Dictionary Stack which includes (i) a read only dictionary ("systenndict") which d^ines the implementation of 
the various PostScript® operators, (ii) a writable dictionary ("userdict") which stores all other definitions, and (iii) 
specialized dictionaries created by the user (e.g.. an imposition dictionary); and 

(4) a Graphics State Stack which is used to store graphics information, such as the parameters of the demand 
printer 84. 

The PostScript® language is device indeperxjent such that the page descriptions contained in the merged Post- 
Script® file 450 are specified in a coordinate system (called "user space") that is independent of the particular demand 
printer 84. The coordinate system (called "device space") used by the demand printer 84 varies depending on the par- 
ticular demand printer 84 (the "current device") which is specified for rendering the current page. In order to render the 
pages described in the merged PostScript® file 450, the page descriptions (specified in user space) may be trans- 
formed to the current device space by a Current Transformation fy/latrix ([CTM]). 

The PostScript® language uses the Current Transformation Matrix ([CTM]) to describe scaling, rotation, and trans- 
lation of the page from user space to device space. For mapping the point (x. y) in user space to the point (x', y*) in 
device space: 

[CTM] = [a b c d t ty], where x' = ax + cy+tx/ = bx + dy + ty 

where a. b, c, and d determine the extent of scaling and rotation and where t^ and ty determine the extent of translation. 
The RIP 82 also maintains a data structure, called the "graphics state," that holds various graphics control param- 



20 



EP 0 858 041 A2 



eters. including the [CTM]. The graphics state also includes (i) a clipping path, which defines the rendering area in the 
raster memory 452 for the current page, (ii) font and line definitions; (iii) a color space (such as DeviceGray, RGB, 
CMYK or CIE); and (iv) other graphics control parameters. 

The PostScript® language includes several operators for setting up the cun-ent demand printer 84 to fulfill the 

5 processing requirements of the page descriptions contained in the merged PostSaipt® file 450. The current device 
setup includes establishing the Cun*^ Transformation Matrix ([CTM]) for the current demand printer 84. The default 
transformation from user space to device space for the current device is specified by a "system default matrix." The sys- 
tem default matrix may be generated by the PostScript® language, for example, by a defaultmatrix operator. The [CTM] 
may be considered an alteration of the system default matrix. 

10 Once the current demand printer 84 has been set up, the RIP 82 can begin to interpret the page descriptions in the 
merged PostScript® file 450. For each page in turn, everything that is to appear on that page (including text, graphics, 
and images) is "painted" into the raster memory 452 and stored andVor rendered by the demand printer 84. 

In the merged PostScript® file 450. each description of a page to be rendered includes a PostScript® showpage 
operator. The showpage operator, which is generally included at the end of each page description, is used to transmit 

75 the raster description of the current page (saved in the raster memory 452) to the demand printer 84 for physical ren- 
dering of the current page. In general, the showpage operator transmits the contents of the raster memory 452 to the 
demand printer 84, then erases the current page from the raster memory 452 and. partially resets the graphics state in 
preparation for interpreting the next page description in the merged PostScript® file 450. 

In level 2 PostScript® Implementations, the function of the showpage operator is controlled by an EndPage proce- 

20 dure and a BeginPage procedure that are defined according to the current demand printer 84. In general, the EndPage 
procedure specifies the disposition of the current page in the raster memory 452 and the BeginPage procedure sets up 
and marks the beginning of the next page description to be interpreted. These procedures may be defined, for example, 
by a level 2 setpagedevice operator which sets up the graphics state for the current demand printer 84 (the "cun-ent 
graphics state"). 

25 During normal operation, the level 2 showpage operator provides two operands to the EndPage procedure: a rea- 
son code and Pagecount. The reason code operand specifies whether the EndPage procedure is being called by the 
showpage operator, by a copypage operator, or during a device deactivation. When the EndPage procedure is called 
by the showpage operator, the reason operand is set to 0. The Pagecount operand is the number of executions of the 
showpage operator that have occurred since the current device was activated, not includirig the present execution. 

30 Thus. Pagecount is equal to the number of pages that have been rendered prior to the current page. After the EndPage 
procedure is executed, Pagecount is incremented by one and is provided as an operand to the BeginPage procedure. 

The operation of the level 2 showpage operator is illustrated in the flowchart of Fig. 20. A block 500 first sets the 
reason code operand equal to zero to specify that the EndPage procedure is being called by the showpage operator. A 
block 502 then calls the EndPage procedure, which consumes the reason code and PageCount operands and returns 

35 a boolean result that specifies the disposition of the current page in the raster memory 452. During normal operation, 
the EndPage procedure returns true during execution of the showpage or copypage operators (causing a physical page 
to be produced) and returns false during device deactivation. A decision-making block 504 determines whether the 
result returned from the EndPage procedure is true or false. 

If the EndPage procedure returns "true", a block 506 transmits the contents of the raster memory 452 to the 

40 demand printer 84 for rendering. A block 508 then clears the raster mernory 452 by executing a procedure similar to a 
PostScript® erasepage operator. Under normal operation, the EndPage procedure returns true if it is called by the 
showpage or copypage operator. Thus, the showpage and copypage operators cause the contents of the raster mem- 
ory 452 to be transmitted to the demand printer 84 for rendering. 

If the EndPage procedure returns a "false", the showpage operator does not perform either of the functions of the 

45 blocks 506 and 508 (i.e., no page is rendered), but skips to a block 510. The block 51 0 executes a procedure similar to 
a PostScript® initgraphics operator which resets the [CTM], the clipping path, and other graphics parameters to the 
default values for the current demand printer 84. thus setting up the graphics state for composing the next page. The 
clipping path defines the rendering area for the current page stored in the raster memory 452. 

A block 512 then increments the Pagecount operand by one and a block 514 calls the BeginPage procedure with 

so Pagecount as an operand. The BeginPage procedure marks the beginning of the next page in the merged PostScript® 
file 450 to be interpreted by the RIP 82. 

The standard operation of the level 2 showpage operator illustrated in Fig, 20 may be represented by the following 
PostScript® pseudo code: 

55 
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/showpage { 

/reason 0 def 



k 

% 
% 
% 



reason = 0 f or 

showpage 

call EndPage 

procedure 

\ do these lines 

\ only 

/ if Endpage 
/ recums true 
sec default graphics 
state 

% increment 
% pagecount 
call BeginPage 
procedure 



pagecount reason EndPage 



{ transmit contents of 
raster memory to 
demand printer 
erasepage } if 



initgraphics 



/pagecount pagecount i add def 



pagecount BeginPage 



% 
% 



} def 



The Impos ition-Qn-The-Rv Procedure 

The imposition-on-the-f ly procedures of the present invention create a layer on top of the demand printer, called a 
"virtual device." The desired position (scale, orientation and size) of a page to be printed by the demand printer is spec- 
ified by a procedure (called "setvirtualdevice") which establishes the virtual device for that page. Thus, from the stand- 
point of the PostScript® program, the [CTM] is the same as the system default matrix and every page begins with a 
[CTM] mapping user space coordinates to the lower left corner of the output device. The [CTM] can be explicitly manip- 
ulated as if each PostScript® page were imaged on a distinct, but identical, physical page. 

Thus, when imposing and rendering a selected page from the merged PostScript® file 450, the current output 
device (i.e. the demand printer 84) is defined as the virtual device. In general, the virtual device for a selected page is 
the same size as the page and is positioned at the place on the flat 456 where the page is to be rendered. 

The virtual device is established by setting the current transformation matrix ([CTN/I]) to properly position the page. 
A dipping path, which defines the rendering area in the raster memory 452, is then created around the border of the 
page. Thus, the RIP 82 "sees" the position where the page is to be rendered as the current output device. 

For pages in the merged PostScript® file 450 that will not be rendered on the current flat 456 (i.e. are not induded 
in the current book), the current output device (the demand printer 84) is defined as a scaled-down virtual device for the 
next page to be imposed and rendered on the flat. The scaled-down virtual device allows any intervening pages not to 
be imposed on the flat to be quickly interpreted by the RIP 82. 

> The imposition-on-the fly procedures include the setvirtualdevice procedure, which establishes the virtual device 
for the next page to rendered on the flat 456 and an EnableVirtual Device procedure which sets up the showpage oper- 
ator to support virtual devices. The EndPage and BeginPage procedures that are invoked by the showpage operator 
are also redefined. These procedures will be described in detail below. 

The Imposition-on-the-Ry Instruction Set: 



Preferably, the instruction set for implementing imposition-on-the-f ly by creating the virtual device for pages to be 
rendered on the flat are input to the RIP 82 in the below-described format. However, the present invention may be mod- 
ified to properly impose different instruction set formats. 

The imposition-on-the-f ly instruction set contains the name(s) of the merged PostScript® file(s) 450 that will be 
interpreted by the RIP 82 and rendered by the demand printer 84. These file names are associated with entry lists 
(stored in arrays) containing one or more entries, wherein each entry contains the following information: 

1) A first us er procedure - The user procedure may contain various instructions, including comments, printer's 
marks (such as barcodes or watermarks) or other information. (The user procedure may also be null and is not 
essential to the imposition-on-the-fly procedures of the present invention). 

2) A page number - The page number is the sequential number of the page description in the merged PostScript® 
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file 450 of the page to be rendered on the flat 456. The merged PostScript® file 450 is assumed to contain page 
descriptions in sequential order, wherein the first page description is page "0/ 

3) Operands to the setvirtualdevice procedure - As explained in detail below, the setvirtualdevice procedure estab- 
lishes the appropriate virtual device as the current output device for a particular page. The setvirtualdevice proce- 
dure requires the following three operands, which are included in each entry in the entry list; 

i) the scaling, translation and rotation factors which will be used to generate a "virtual [CTM]" which will properly 
position the selected page on the flat 456. These factors are listed as follows; [ scaie_x sealery translate_x 
translate_y rotate]; 

ii) the user space coordinates of the lower-left and upper-right corners of the actual rendering area of the next 
page to be rendered on the flat 456. These corner coordinates will be used to generate a clipping path around 
the border of the page in the raster rriemory 452. The corner coordinates are listed as follows: [ClipIIX ClipllY 
ClipurX ClipurY]; and 

iiO the size (width and length) of the page to be rendered on the flat The page size is listed as follows: [PageX 
PageY]. (The page size is not necessarily equivalent to the dipping path defining the rendering area of the 
page, as many demand printers are unable to place marks at the extreme edges of the page). 

4) A second user procedure ("offsets") : Like the first user procedure, the second user procedure may contain com- 
ments, printer's marks (barcodes, watermarks, etc.) or other information or may be null. In a preferred embodiment, 
however, for the first page on the flat, the second user procedure is used to "offset" the program to the next page 
to be rendered on the flat. 

For example, the merged PostScript® file generally contains many, many pages because it includes separate page 
descriptions for each variable page. Assume a simple four page book with three master pages and only one variable 
page. The book may be sent to 1.000 different people, with different variable information for each person. Thus, the 
merged PostScript® file contains 1.003 page descriptions - 3 master pages and 1.000 variable pages. Imposition-on- 
the-fly with offsets allows for quick printing of the books because it "skips over" (i.e. does not RIP) the 999 variable 
pages that will not be included in each book. 

For imposition-on-the-fly with offsets, the second user procedure for the first entry in the instruction set contains a 
file object, an offset position and the PostScript® setfileposition operator. The offset position points to the next page 
description in the file that is to be included on the flat. (The offset positions were calculated and saved by the block 364 
of Fig. 13.) The setfileposition operator repositions the current merged PostScript® file 450 to that offset position. 

Thus, the PostScript® instruction set format for imposition-on-the-fly imposition of the present invention is as fol- 
lows: 

I (FileName) 

[ { user procedure 1 } 
page# { operands to setvirtualdevice } 
{ FileObjecc of feet setfileposition ) 

] 

( { user procedure 1} 
page# { operands to setvirtualdevice } 
{ user procedure 2 - barcodes, watermarks, etc. } 

] 

J 



A sample imposition-on-the-fly with offsets instruction set is attached as Appendix 1. The Appendix 1 instruction set 
also includes code in certain second user procedures to print a barcode. 

Explanation of Variables: 

The variables used by the imposition-on-the-fly procedures may be conveniently defined and stored in a user dic- 
tionary (called, for example, "irrpositiondict"). These variables include: 

1) PageOffset - the cumulative number of pages from any previous PostScript® files that have been interpreted in 
accordance with the imposition-on-the-fly procedures of the present invention. Initially. PageOffset is set to -1 (no 
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previous files (or pages) have been interpreted). 

2) CurrentPage - the number of the next page in the current merged PostScript® file 450 that is to be. rendered on 
the current fiat 456. CurrentPage is initially set to 0. 

3) LastPage - the number of the last page in the current merged PostScript® file 450 that is to be rendered on the 
current fiat, which is equal to the page number in the last entry of the entry list. LastPage is initially set to 1 arxi is 
used to determine how many page descriptions in the merged PostScript® file must be interpreted in order to prop- 
erly render all of the selected pages on the current flat. 

4) PageCount - the number of times that the showpage operator has been executed (initially 0). In level 2 Post- 
Script® implementations, PageCount is stored and incremented internally by the RIP 82 through the showpage 
operator. However, in level 1 PostScript® implementations, the PageCount variable must be explicitly defined and 
incremented to emulate the operation of the level 2 showpage operator. 

5) PageList - the list of entries (page numbers and imposition procedures) contained in the entry list. 

6) Curreint Index - an index into the PageList. 

7) Lastlndex - the number of entries in the entry list. 

8) DefaultMatrix - used to store the value of the [CTM] describing the virtual device (the "virtual [CTM]"). The scal- 
ing, translation and rotation components of the virtual [CTM] are supplied as operands to the setvirtualdevice pro- 
cedure. 

9) PageX and PageY - the width and height respectively of the page to be rendered on the flat 456. The values of 
PageX and PageY are provided in each entry of the entry list as operands to the setvirtualdievice procedure. 

10) DefaultPageX and DefaultPageY - the default values of the page width and height, respectively. Their values 
are initially set to 8 1/2" (612) and 1 1 " (792). respectively. 

11) ClipllX. ClipllY, ClipurX and ClipurY - the user space coordinates of the lower-left and upper-right corners, 
respectively, of the clipping path defining the border of the virtual device. The values of these variables are also 
included as operands to the setvirtualdevice procedure. 

12) Portrait - a boolean variable used to describe the page orientation of the current page. If Portrait is true, the cur- 
rent page has a portrait orientation (page width < page height). If Portrait is false, the current page has a landscape 
orientation (page width > page height). 

13) DefaultPortrait - the default value for the page orientation, which is initially set to true (portrait orientation). 

14) VirtualDeviceEnabled - a boolean variable used to determine whether a procedure called, for example. "Ena- 
bleVirtualDevice," has been executed. As explained in detail below, the EnableVirtualDevice procedure sets up the 
standard PostScript® showpage operator to support virtual devices. 

15) ImageDone - a boolean variable used to specify when the current flat 456 has been completed. ImageDone is 
initially and normally set to felse. indicating that the current flat 456 has not been completed. 

A further description of the variables used is included in the following PostScript® code, which creates the imposi- 
tiondict dictionary and initializes the variables: 
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/iinposiciondicc 200 diet def V create dictionary 

t in^josiciondict begin 

used as input to setmatrix 
dumrtty matrix for temp storage 
duinmy matrix for temp storage 
dummy matrix for temp storage 
dummy matrix for temp storage 
default page width (X) and 
page length (Y) (8 1/2" x 
11") 

% assume page orient = 
% portrait 
% first file - no previous 
% pages 

/CurrentPage 0 def % initial value of page to 

5r impose 

/Currentlndex 0 def % initial value of page to 

h impose 

/LastPage 2147463647 def % initial value is highest 

^ number 

/PageCount 0 def % used in level l only 

/DefaulcMatrix matrix k the "default- matrix for the 

currentmatrix def % current virtual device 

/VirtualDeviceEnabled false def % allow normal 

% operation 

/ImageDone false def k not done with current media 

% Set initial job defaults 
/Portrait Def aultPortrait def % default to portrait 

% mode 



/Identity matrix def % 
/Matrix matrix def % 
/Matrix2 matrix def % 
/Matrix3 matrix def % 
/Matrix4 matrix def % 
/DefaultPageX Sl2 def % 
/DefaultPageY 792 def % 

% 

/DefaultPortrait true def 
/PageOffset -1 def 



/PageX DefaultPageX def % 
/PageY DefaultPageY def \ 
/Cliplix 0 def % 
/ClipllY 0 def ^ 
/ClipurX DefaultPageX def 
/ClipurY DefaultPageY def 



initial page size 

initial lower left 
and upper right 

% comers of 
% clipping path 



The Redefined PostScript® Operators: 

Also, before executing the imposition-on-the-fly procedures of the present invention, several PostScript® operators 
must be redefined for compatibility with the EnableVirtualDevice and setvirtualdevice procedures, which will be 
described in detail below. The virtual device, in effect, "shields" the PostScript® program and RIP from where the pages 
are being painted into the raster memory 452 through the [CTM]. Thus, in general, the PostScript® operators that affect 
the [CTM] must be redefined to also "shield" the PostScript® program and RIP from the final mapping of the page 
desCTiption from user space to device space coordinates. The PostScript® operators which must be redefined include: 



initmatrix 
inttclip 



transform 
itransform 
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setmatrix dtransform 
currentmatrix idtransform 
erasepage nulldevice 
initgraphics copypage 

5 

The standard operation oi these, and ail other PostScript® operators, is fully described in the PostScript® Language 
Reference Manual, Second Edition (1 990), from Adobe Systems, Inc., which was previously incorporated by reference. 

The first step in redefining the above-listed PostScript® operators is to rename the standard operator, for example, 
"systemdict_operator." because its definition is stored in the systemdict dictionary. This may be implemented by the foi- 
10 lowing code: 

/systemdict J nitmatrix systemdict /initmatrix get def 

/systemdict J nitciip systemdict /initclip get def 

/systerrxiict_setmatrix systemdict /setmatrix get def 
75 /systemdict_erasepage systemdict /erasepage get def 

/systemdictjnitgraphics systemdict /initgraphics get def 

/systemdict_currentmatrix systenrdict /currentmatrix get def 

/systemdict_transform systenndict /transform get def 

/systemdictjtransform systenrdict /itransform get def 
20 /systenrtdictjdtransform systemdict /dtransform get def 

/systemdict Jdtransform systemdict /idtransform get def 

As explained below, the standard nulldevice and copypage operators are not renamed because their standard opera- 
tion will never be used in connection with the present invention. The new definitions of the operators; described below, 
25 are then loaded into the userdict dictionary. 

The Redefined initmatrix Operator: 

The standard PostScript® initmatrix operator sets the [CTM] to the system default matrix for the current device. The 
30 initmatrix operator is redefined to set the [CTM] equal to the virtual [CTM] which defines the virtual device. 
The virtual [CTM] may be stored in the variable DefaultMatrix. 

The PostScript® initmatrix operator may be redefined by the following code: 

/initmatrix { 

imposiciondict begin 

DefaultMatrix 

systemdict_setmatrix 

end 
) bind def 

40 ' 



45 The Redefined initclip Operator: 

The default clipping path corresponds to the boundary of the maximum imageable area for the current output 
device (the demand printer 84). The standard PostScript® initclip operator replaces the current clipping path in the 
graphics state with the default clipping path for the current demand printer. The initdip operator is redefined to replace 
so the current clipping path in the graphics state with a clipping path defining the border of the virtual device page. 

The flowchart of Rg. 21 illustrates the program steps implemented by the redefined initdip operator. A dedsion- 
making block 520 determines whether a current path exists by checking for the existence of a currerrtpoint. If no cur- 
rentpoint is defined, a block 522 stores an empty path in a variable called, for example, "p1 Alternatively, if a current- 
point is defined, a block 524 invokes a previously defined utility routine called, for example. "MakePath." that creates a 
55 path description from the current path. The block 524 then saves the current path description in the variable pi. The 
MakePath procedure, which may be stored in the impositiondict dictionary, is similar to the level 2 PostScript® upath 
operator and may be implemented by the following code: 
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/MakePath { ■ 

[ {/moveco cvx} {/lineco cvx) {/curvero cvx} 
{/closepath cvx) pathforall ] cvx 

} bind def 



Next, a block 526 saves the current [CTM] and a block 528 sets the [CTM] to the virtual [CTM]. A block 530 then 
creates a clipping path between the corners of the virtual device, which were specified by the values of the ClipllX, Cli- 
pllY ClipurX arxj ClipurY variables provided as operands to the setvirtualdevice procedure. A block 532 then restores 
the [CTM] which was saved by the block 526 and the current path saved In the variable pi . 

The PostScript® initdip operator may be redefined by the following code: 

/initclip 

imposiciondict begin 
{ currentpoinc .} stopped 

( /pi { } def } % pi = empty path 

{ pop pop /pi MakePath def} % pi = current 



if else 

matrix systemdict_currentmatrix 
initmatrix 
systemdict:_inicclip 
newpath 

ClipllX ClipllY moveto 
ClipurX ClipllY lineto . 
ClipurX ClipurY lineto 
ClipllX ClipurY lineto 
closepath 
clip 
newpath 

systemdict^setmatrix 
Pl 

end 

) bind def 



* path 



% create clippath 



restore current 
?r path 



The Redefined setmatrix Operator: 

The standard PostScript® setmatrix operator replaces the current [CTM] In the graphics state with a matrix that is 
supplied on the Operands stack. The matrix supplied on the Operands stack ("the operand matrix") can be considered 
the result of the concatenation of the system default matrix with an operations matrix. 

The setmatrix operator is redefined to calculate the operations matrix by concatenating the operand matrix with the 
inverse of the system default matrix. Thus. 

[operand matrix] = [operations matrix] [system default matrix], 

and 

[operations matrix] = [operand matrix] [system default matrix] . 

Once the operations matrix is calculated,- it is concatenated with the virtual [CTM] (stored in DefaultMatrix)-and saved - 
as the new [CTM]. Thus, 
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new [CTM] = [operations matrix] [virtual CTM]- 
The PostScript® setmatrix operator may be redefined by the following code: 

/setmatrix { 

impositiondict begin 
Matrix def aultmatrix 
Macrix2 inverctnacrix 
Matrix3 concatmatrix 
Def aulcMacrix 
Matrix4 concatmatrix 
systemdict_setinatrix 
end 

} bind def 



The Redefined currentmatrix Operator: 

The standard currentmatrix operator replaces the matrix supplied on the Operands stack with the current [CTM] in 
the graphics state. 

The current [CTM] can be considered the result of concatenating the virtual [CTM] (saved in DefaultMatrix) with an 
operations matrix. The redefined currentmatrix operator calculates the operations matrix by concatenating the current 
[CTM] with the inverse of the virtual [CTM] as set forth below: - 

[current CTM] = [operations matrix] [virtual CTM], 

and 

[operations matrix] = [cun-ent CTM] [virtual CTM] . 

The [operations matrix] is then concatenated with the system default matrix and the resultant matrix is stored in the 
matrix on the Operands stack. 

The PostScript® currentmatrix operator may be redefined by the following code: 

/currentmatrix { 

impositiondict begin 

Matrix systemdict^currentmatrix 

DefaultMatrix 

Matrix2 invertmatrix 

MatrixS concatmatrix 

Matrix4 def aultmatrix 

3 -1 roll 

concatmatrix 

end^ 
) bind def 



The Redefined erasepage Operator: 

The standard erasepage operator erases the entire current page stored in raster memory by painting the page 
white. The erasepage operator is redefined to erase only the virtual device page, which is the area defined by the next 
page to be rendered on the cun-errt flat 
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The erasepage operator is redefined by calling the redefined inrtcfrp operator, desaibed above, which establishes 
a clipping path around the border of the virtual device page. The area inside the clipping path is then painted white. The 
standard PostScript® gsave operator (described in detail in connection with the optional inrtposition-on-the-fly proce- 
dures of the invention ) is called immediately before the redefined initclip operator to save the current graphics state, 
including the current clipping path, gray level, etc. Also, after the virtual device page has been painted white, the stand- 
ard PostScript® grestore operator (also described in detail in connection wrth the optional procedures) is called to 
restore the current graphics state. 

The PostScript® erasepage operator may be redefined by the following code: 

/erasepage { 

impositiondicc begin 

gsave % syscemdict_gsave for opcional procs 

inicciip 

clippath 1 setgray fill 

grestore % syscemdict^grestore for optional 

*• procs " 

end 
} bind def 

(In the optional imposition-on-the-fly procedures, the standard PostScript® gsave and grestore operators are redefined. 
Thus, in the optional procedures, the erasepage operator is redefined by calling the systemdict_gsave and 
systemdict grestore operators, as specified above.) 

The Redefined initgraphics Operator: 

The standard PostScript® initgraphics operator resets several values in the graphics state, including the [CTM], the 
current path and the clipping path, to their default values. The standard initgraphics operator is equivalent to the follow- 
ing PostScript® language sequence: 

initmatrix newpath initclip 

1 setlinewidth 0 setlinecap 0 setlinejoin 

D 0 setdash 0 setgray ,1 0 setmiteriimit 

The initgraphics operator is redefined to perform the above listed sequence. However, the redefined initgraphics 
calls the redefined initmatrix and initclip operators, which were described above. Thus, the redefined initgraphics oper- 
ator resets the [CTM] and the clipping path to their default values for the virtual device. 

The PostScript® initgraphics operator may be redefined by the following code: 

/initgraphics { 

initmatrix newpath initclip 

1 setlinewidth 0 setlinecap 0 setlinejoin 

[] 0 setdash 0 setgray 10 setmiteriimit 

) bind def 



The Redefined "transform" Operators: 

The standard PostScript® transform operator transforms a supplied user space coordinate (x.y) to the correspond- 
ing device space coordinate (x'.y') as specified by the [CTM]. Since the [CTM] is altered during the imposition process, 
the transform operator is redefined to perform the transformation as if the [CTM] had not been altered. 

If a matrix operand is supplied to the standard transform operator, the transformation from user to device space is 
performed according to the supplied matrix. Thus, if a matrix operand is supplied, the transform operator is also rede- 
fined to perform the transformation according to the supplied matrix. 

The PostScript® language includes three other "transform" operators (dtransform. itransform and idtransforn) 
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10 



15 



20 



25 



which are redefined in the same manner as the transform operator. 

The standard PostScript® dtransform operator specifies a "distance" transformation of a coordinate from user to 
device space according to the [CTM] or a supplied matrix operand. In a distance transformation, the translation compo- 
nents (tx and ty) of the [CTM] are not used. 

The standard PostScript® rtransform operator specifies a transfornration of a coordinate in device space (x*,/) to 
user space (x,y) according to the inverse of the [CTM] or a supplied matrix operand. The standard idtransform operator 
specifies a distance transformation from device space to user space according to the inverse of the [CTM] or a supplied 
matrix operand. 

Fig. 22 illustrates the program steps Implemented by the redefined transform operator The other transform opera- 
tors are redefined in the same way. A decision-making block 534 first determines whether a matrix operand was sup- 
plied to the transform operator. If a matrix operand was supplied, a block 536 sinrply calls the standard transform 
operator (now renamed "systemdictjransform") to perform the transformation according to the supplied matrix. (For 
the other transform operators, the block 536 calls systenxJictjdtransform, systemdict_itransform or 
systemdictjdtransform). 

Alternatively if the block 534 determines that a nratrix operand was not supplied, a block 538 first saves a copy of 
the current [CTM] in the graphics state on the Operands Stack. 

As explained previously, the current [CThA\ can be considered the result of the concatenating the virtual [CTM] 
(saved in DefaultMatrix) with an operations matrix. A block 540 thus calculates the operations matrix by concatenating 
the current [CTM] with the inverse of the virtual [CTM]. 

Next, a block 542 sets a new [CTM] equal to the operations matrix concatenated with the system default matrix. 
The new [CTM] is now equal to what the [CTM] would have been if the setvlrtualdevice and imposition procedures were 
not implemented. 

A block 544 then calls the standard transform operator to perform the transformation from user to device space 
according to the new [CTM]. (Again, for the other transform operators, the block 544 calls the standard dtransform, 
itransform, or idtransform operator). 

Lastly, a block 546 resets the [CTM] equal to the current [CTM] saved on the Operands Stack by the block 538. 

The PostScript® transform operators may be redefined by the following code: 
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/trans form { 

impositiondict begin 
dup type /arraytype eq ( 
sy3Cemdict_transf orm 
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45 



so 



% or systrrvdict^dtransf orm 



^ or 



% systemdict_i trans form 
% or systeindict_idtransf orm 



} { 

Matrix systemdict_currencinatrix 
dup 4 1 roll 
DefaultMatrix 
Ma t r ix2 inver tma t r ix 
Matrix3 concatmatrix 
Matrix2 def aultmatrix 
Matrix4 concatrrvatrix 
systemdict_setmatrix 
sy s t emdict_trans f orm 



or 



systemdictjdtransform 
% or systemdict_itransf orm 
% or systemdict_idtransf orm 
-1 roll systemdict^setmatrix 
ifelse 



end 
} bind def 
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The Redefined nulldevice Operator: 

The standard PostScript® nulldevice operator installs a "null device" as the current output device. The standard 
PostScript® nulldevice operator produces no physical output and has no associated raster memory. However, any 
graphics or font operations executed will be saved in the current graphics state. The PostScript® nulldevice operator 
also sets the [CTM] to an identity matrix ([1 00 1 0 0]) and establshes the clipping path as a single point at the origin. 

The standard PostScript® nulldevice operator, however, is not suitable for use with this invention because is not a 
page device operator and, therefore, has no EndPage and BeginPage procedures associated with it. Thus, the nullde- 
vice operator is redefined to set the [CTf^ to the identity matrix and establish a one point clipping path without altering 
the current page device. 

The PostScript® nulldevice operator may be redefined by the following code: 

/nulldevice { 

imposiciondicc /Idencity gee 

syst:eindicc_S€ninacrix . 

newpath 

clip 
} bind def 



The Redefined copyage Operator: 

25 

Under normal operation, the standard PostScript® copypage operator transmits one copy of the current page to the 
demand printer without erasing the current page or changing the graphics state. Like the showpage operator, the oper- 
ation of the copypage operator depends on the EndPage and BeginPage procedures, which are redefined by the 
present invention. In the present invention, the EndPage and BeginPage procedures are redefined so that the copypage 
30 operator has no affect. The EndPage and BeginPage procedures could be redefined to check for the copypage operator 
(by comparing the reason code to one). Alternatively, the operation of the copypage operator can simply be nulled by 
the following code: 

/copypage { } def 

35 " 

The EnableVlrtualDevice Procedure: 

The EnableVirlualDevice procedure, which is called by the ImposeJob procedure at the end of the instruction set, 
sets up the showpage operator to support virtual devices. Fig. 23 is a flowchart illustrating the program steps imple- 
40 mented by the EnableVirtualDevice procedure. A block 550 first determines whether the RIP 82 implements level 1 or 
level 2 PostScript® by determining whether the PostScript® setpagedevice operator is defined in the systemdict dic- 
tionary. If the RIP 82 implements the level 2 PostScript® language, a block 552 loads the redefined EndPage and 
BeginPage procedures into the current graphics state for the demand printer 84 by calling the setpagedevice operator. 
As described in detail below, the EndPage and BeginPage procedures are redefined to define the current output device 
45 as a virtual device for pages to be rendered or as a scaled-down virtual device for non-rendered pages. 

The blocks 550 and 552 of the EnableVirtualDevice procedure may be implemented by the following code: 



so 
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/EnablevircualDevice { 

/secpagedevice where { % level 2 

pop 

2 dice begin 

/EndPage impositiondicc /EndPage get def 
/BeginPage impositiondicc /BeginPage get 
def 

currentdict end 
setpagedevicB 



Alternatively, if the block 550 determines that the RIP 82 implements level 1 PostScript®, a block 554 renames the 
standard level 1 showpage operator and a block 556 redefines the showpage operator to emulate the operation of the 
level 2 showpage operator as illustrated in Fig. 20. Next a block 558 executes the BeginPage procedure for the first 
page (page "0") in the merged PostScript® file 450. (This was done automatically in the level 2 implementation by the 
block 552 by calling the setpagedevice operator). 

The blocks 554-558 may be innpiemented by the following code: 

{ impositiondict /syscemdict^showpage % renstme 

systemdict /showpage get put % showpage 

/showpage { % emulate 

impositiondict begin % level 2 
PageCount 0 EndPage 
sy 3 1 emdic t_showpage 

} if 

systetcidict_initgraphics 

/PageCount PageCount 1 add def ' . 

PageCount /BeginPage load end exec 
} def 

0 impositiondict /BeginPage get exec 
} ifelse 



Next, a block 560 invokes a procedure (called, for example. "DisablePageDevice") which was previously stored in 
the impositiondict dictionary. The DisablePageDevice procedure redefines the PostScript® setpagedevice operator and 
all other compatibility operators that call the setpagedevice operator. Disabling these operators ensures that the raster 
memory 452 (which may contain the raster descriptions of previously processed pages to be rendered on the flat 456) 
is not erased by the setpagedevice operator. The DisablePageDevice procedure is described in detail below in connec- 
tion with Fig. 24. 

After the block 560 invokes the DisablePageDevice procedure described above, a block 562 sets the boolean var- 
iable called "VirtualDeviceEnabled" to true to indicate that the procedure has been completed and the showpage oper- 
ator is set up to support virtual devices. 

The blocks 560 and 562 of the EnableVtrtualDevice procedure may be implemented by the following code: 



impositiondict /DisablePageDevice get exec 
impositiondict A/irtualDeviceEnabled true put 
} bind def 



The OisablePageDevice Procedure: 

Fig. 24 is a flowchart illustrating the program steps implemented by the DisablePageDevice procedure, which is 
invoked by the block 560 of the EnableVirtualDevice procedure. Because setpagedevice is a level 2 operator, a block 
570 determines whether the RIP 82 implements the level 1 or the level 2 PostScript® language by determining whether 
the setpagedevice operator is defined in the systemdict dictionary. If the RIP 82 inrplements the level 2 PostSaipt® lan- 
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guage, blocks 572-580 redefine the setpagedevice operator to correct the page orientation of the output device. If nec- 
essary. 

During normal level 2 operation, a dictionary operand containing input media selection entries is provided to the 
PostScript® setpagedevice operator and the setpagedevice operator establishes the current output device according 

5 to the information contained in the current graphics state and the dictionary operand. The dictionary operand may con- 
tain, for example, an entry for PageSize, which is an an-ay of two numl>ers indicating the width and height of the current 
page. Thus, a call to the setpagedevice operator may alter the page size, which is critical In setting up the virtual device. 

The block 572 of the redefined setpagedevice operator first determines whether an entry for PageSize was 
included in the dictionary operand to the setpagedevice operator. If so, the block 574 then determines whether the Pag- 

10 eSize specified in the entry is.portrait or landscape orientation by comparing the page width to the page height supplied 
in the PageSize entry. (As explained above, for purposes of the invention, if the page width is less than the page height, 
the orientation is referred to as portrait and the variable Portrait is set to true. If the page width is greater than the page 
height, the orientation is referred to as landscape and the variable Portrait is set to false). 

A block 576 then compares the page orientation of the PageSize entry (determined by block 574) to the page ori- 

15 entation of the virtual device (stored in the variable Portrait). If they are not the same, a block 578 invokes a procedure 
called, for example, "SetPortrait," which changes the orientation of the virtual device from portrait to landscape, or vice 
versa. (The SetPortrait Procedure is described in detail below). Next, for consistency, with the normal operation of the 
setpagedevice operator, a block 580 calls the redefined initgraphics and erasepage operators. Alternatively, if the block 
576 determines that the page orientation of the PageSize entry Is the same as the virtual device, or If the block 572 

20 determines that PageSize was not included In the dictionary operand to the setpagedevice operator, the program skips 
directly to the block 580. which completes the redefinition of the setpagedevice operator. 

The blocks 570-580 of the DisablePageDevice procedure may be Implemented by the following code: 

/DisablePageDevice { 

/secpagediervice vhere { 
pop 

uflexrdLict; 
/setpagedevice { 

diip / Page Size known { 

/PageSize get 
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imposi t iondict begin 
aload pop 
It Portrait: ne { 
SetPortrait 

} if 

end 

} ( 
^op 



45 } ifelse 

initgraphics 
erasepage 

} put 

} if 



After the block 580 calls the redefined initgraphics and erasepage operators, or if the block 570 determines that the 
RIP 82 implements level 1 PostScript®, a block 582 redefines the compatibility operators, which are defined In either 
the statusdict dictionary or the userdict dictionary, which call the setpagedevice operator or perform similar level 1 oper- 
55 atlons. 

For compatibility operators that change the page orientation, the block 582 redefines the operator to set the orien- 
tation of the virtual device equal to the orientation of the page specified by the operator and to Initialize the virtual 
device. These operators may be redefined by a utility routine called, for example, "SetPageSlze." which Is similar to the 
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blocks 576-580 described above. The SetPageSize routine may be implemented by the following code: 



10 



/SecPageSize { 

It Portrait ne { 
SetPortrait 

} if 

initgraphics 
erasepage 
} bind def 



% correct oriencacion of virtual 
V device, if necessary 

\ initialize virtual device 
% (emulate setpagedevice) 



For compatibility operators that do not affect the page orientation, the block 582 simply disables or nulls the oper- 
ators. The block 582 of the DisablePageDe/ice procedure, which redefines or disables the compatibility operators, may 
75 be implemented by the following code: 
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stacusdict begin % operators in statusdicc 

/a3t:ray ( imposiciondicc begin 842 792 SecPageSize end} 
def 

/a4t:ray {impositiondict begin 595 842 SecPageSize end} 
def 

/ledgercray {imposiciondicc begin 1224 792 SecPageSize 
end} def 

/seepage {pop pop pop} def 
/secpagescaclcorder (pop} def 
/seccumble (pop} def 

/llxl7cray {imposiciondicc begin 792 1224 SecPageSize 
end} def 

/bScray {imposiciondicc begin 516 729 SecPageSize end} 
def 

/iegalcray (imposiciondicc begin 612 1008 SecPageSize 
end} def 

/secdef aulccimeoucs (pop} def 
/setduplexmode {pop} def 
/secmargins (pop pop} def 
/secpagemargin {pop) def 

/leccertray {imposiciondicc begin 612 792 SetPageSize 
end} def 

/secmirrorprinc (pop} def 
/secpageparams (pop pop pop pop} def 
/secresolution (pop} def 
end 

% operacors in userdict 
/a3 (imposiciondicc begin 842 1191 SeCPageSize end} def 
/b5 {imposiciondicc begin 516 729 SecPageSize end} def 
/letter (imposiciondicc begin 612 792 SecPageSize end} 
def 

/lettersmall (imposiciondicc begin 612 792 SecPageSize 
end} def 

/legal (imposiciondicc begin 612 1008 SecPageSize end} 
def 

/ledger (impositiondict begin 1224 792 SetPageSize end} 
def 

/11X17 (impositiondict begin 792 1224 SecPageSize end} 
def 

/a4 (imposiciondicc begin 595 842 SecPageSize end} def 
/a43mall (imposiciondicc begin 595 842 SecPageSize end} 
def 

/note ( } def 



The SetPortrait Procedure: 

The SetPortrait procedure, which is invoked by the block 578 of the Disable Page Device procedure, changes the ori- 
entation of the virtual device from portrait to landscape or vice versa. Fig. 25 illustrates the program steps implemented 
by the SetPortrait procedure. A block 590 first determines whether the variable Portrait is true (indicating the page is 
portrait) or false (indicating the page is landscape). 

If Portrait is true, the orientation of the device must be converted from portrait to landscape. As illustrated in Rg. 
26A, a portrait-orientated page 592 is represented in a cartesian coordinate system with an origin at point Op The por- 
trait-orientated page 592 has a width PageX and a height PageY. The rendering area on the page 592 is bordered by a 
clipping path 594, which may be defined by the coordinates of Its lower-left corner (llx, lly) and the coordinates of its 
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upper-right corner (urx, ury). 

The portrait-oriented page 592 is converted to a iandscape-oriented page 596 by translating the origin Op of the 
page 592 in the positive x-direction and then rotating the coordinate system 90 degrees counterclockwise, resulting in 
the landscape-orientated coordinate system of the page 596 with an origin O^. Although the device space coordinates 
of the clipping path 594 are unchanged, the clipping path 594 must be redefined with respect to the new landscape 
coordinate system. 

Referring again to Fig. 25. after the block 590 determines that the orientation of the device must be converted from 
portrait to landscape, a block 600 redefines the corner coordinate variables as follows: 



Portrait Coordinate 


Landscape Coordinate 


ClipllX 


ClipllY 


ClipllY 


PageX - ClipurX 


ClipurX 


ClipurY 


ClipurY 


PageX - ClipllY 



Next, blocks 602 and 604 create matrices which will translate the origin Op by the page >Andth (PageX) in the posi- 
tive x-direction and then rotate the portrait coordinate system 90 degrees counterclockwise about the origin Op A block 
606 then concatenates the matrices with the current virtual [CTM] to create the new virtual [CTM], which specifies the 
device in landscape orientation. 

The blocks 590 and 600-606 of the SetPortrait procedure may be implemented by the following code: 

/SetPorcrait. { 
Portraic { 

/cmp ClipllX def 

/ClipllY PageX ClipurX suJo def 

/ClipurX ClipurY def 

/ClipurY PageX cmp suib def 

90 Matrix rotate 

PageX 0 Macrix2 translate 

Def aultMatrix 

Matrix3 concat:inatrix 

Def aultMatrix concatmatrix 

pop 

} 



If the block 590 determines that the variable Portrait is iaise, the orientation of the device must be converted from 
landscape to portrait. Refenring also to Fig. 26B. a landscape-oriented page 608 is specified in a cartesian coordinate 
system with an origin Ol- The rendered area on the page 608 is bordered by a clipping path 610 defined by the coordi- 
nates of its lower-left and upper-right corners. The landscape-oriented page 608 is converted to a portrait-oriented page 
61 2 by translating the origin Ol in the positive y-direction and then rotating the coordinate system 90 degrees clockwise 
about the origin Ol- This generates a portrait-oriented coordinate system with an origin Op 

Similar to the above-described portrait to landscape procedure, a block 614 first redefines the corner coordinates 
of the clipping path as follows: 



Landscape Coordinate 


Portrait Coordinate 


ClipllY 
ClipllX 


ClipllX 
PageY - ClipurY 



36 



EP 0 858 041 A2 



(continued) 



Landscape Coordinate 


Portrait Coordinate 


ClipurY 
ClipurX 


ClipurX 
PageY - CliplIY 



Next, blocks 616 and 618 create matrices to translate the origin Ot_ in the positive y-direction and then rotate the 
origin Ol 90 degrees clockwise. A block 620 then concatenates the matrices with the current virtual [CTM] to generate 
70 the new virtual [CTM], which specifies the device in a portrait coordinate system. 

The blocks 614-620 of the SetPortrart procedure, which convert from landscape to portrait orientation, may be 
implemented by the following code: 

/tmp ClipllY def 
/ClipllY CliplJJC def 
/ClipllX PageY ClipurY sub def 
/ClipurY ClipurX def 
/ClipurX PageY tmp sub def 
-90 Matrix rocace 
0 PageY Mat:rix2 translate 
Def aultMatrix 
Matrix3 concatitvatrix 
Def aultMatrix concatinatrix 
pop 

} ifelse 



20 



After the clipping path corners are redefined and the new virtual [CTM] is generated, a block 622 exchanges the 
30 values of PageX and PageY. Thus, for example, when converting from portrait to landscape, the portrait page width 
becomes the landscape page height and the portrait page height becomes the landscape page width. Lastly, a block 
624 changes the value of the variable Portrait. Thus, if Portrait was initially true (indicating portrait orientation), it is set 
to false to indicate that the device is now in landscape orientation. Conversely, if Portrait was initially false (indicating 
landscape orientation), it is set to true to indicate that the device is now in portrait orientation. 
35 The blocks 622-624 may be inplemented by the following code: 

/tmp PageX def 
/PageX PageY def 
/PageY tmp def 
/Portrait Portrait not def 
} bind def 



45 The SetPortrait procedure described above comprises an optional part of the present invention and is not neces- 
sary for use with PostScript® applications which do not alter the page orientation. 

The setvirtualdevice Procedure: 

The setvirtualdevice procedure establishes the current transformation matrix ([CTTy/l]), the clipping path, and the 
page size such that the current output device is specified as a virtual device/The virtual device is defined to be the size 
of the next page to be rendered, with the origin and page boundary at the position on the flat 456 where the page is to 
be rendered. 

The setvirtualdevice procedure retires the following three "operands," which are provided in the instruction set list: 

1) the imposition procedure, which includes the scaling, translation and rotation factors - [scale_x sealery - 
translate_x translate_y rotate]: 

2) the user space coordinates of the lower-left and upper-right corners of the rendering area of the page to be 
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imposed, which will be used to generate a clipping path around the border of the virtual page in the raster memory 

22 - [clipjl_x cllpjl_y clip_ur_x clip_ur_y]; and 

3) the page width and page length - [page_size_x page_size^]. 

Fig. 27 illustrates the program steps implemented by the setvirtualdevice procedure A block 630 first determines 
whether the variable VirtualDeviceEnabled Is set to true, indicating that the EnableVirtuaiDevice procedure has been 
executed and the showpage operator Is set up to support virtual devices. If the block 630 determines that VirtualDevi- 
ceEnabled is false, a block 633 invokes the EnableVirtuaiDevice procedure. (A block 6333. which is impiemerrted only 
in connection with the optional imposition-on-the-fly-procedures. will be described below.) 

, Next, a block 634 defines the variables PageX and PageY as the width and height of the virtual device, respectively 
Similarly, a block 636 defines the variables ClipllX and ClipllY as the x and y coordinates of the lower-left corner of the 
virtual device and the variables ClipurX and ClipurY as the x and y coordinates of the upper-right corner of the virtual 
device. 

A block 638 then calls the standard PostScript® inltmatrix operator (renamed "systenrxiictjnitmatrix"). which sets 
the [CTM] to the system default matrix for the current output device. A block 640 then executes the scale, translate and 
rotate operators with the operands to the setvirtualdevice procedure. These scale, translate and rotate operations alter 
the system default matrix to specify the virtual [CTM]. A block 642 saves the resultant virtual [CTM] in the variable 
DefaultMatrix. The virtual [CTM] specifies that the origin of the virtual device is at the position on the flat where the next 
page is to be rendered on the flat 456. 

A decision-making block 644 then compares the page width (PageX) to the page height (PageY). If PageX is less 
than PageY, a block 646 sets the variable Portrait to true (indicating portrait orientation). Alternatively, if PageX is 
greater than PageY. a block 648 sets the variable Portrait to false (indicating landscape orientation). 

Next, a block 650 calls the redefined initclip operator to set the clipping path around the border of the virtual page. 
(See Fig. 21). 

The setvirtualdevice procedure may be implemented by the following code: 

/setvirtualdevice { 

imposiciondicn begiia 

VirtualDeviceEnabled not { EnableVirtuaiDevice } if 
aload pop 

/PageY exch def k set page size 

/PageX exch def 
aload pop pop 

/ClipurY exch def % set clipping path corners 

/ClipurX exch def 

/ClipllY exch def 

/ClipllX exch def 

systetndict_initinatrix 

aload pop 

5 -2 roll scale % execute scale, translate 

3 -2 roll translate k and rotate 

rotate 

DefaultMatrix systemdict^currentmatrix pop % set 

% [CTM] 

/Portrait PageX PageY It def 

initclip V set clipping path 

end 
} bind def 



The ImposeJob Procedure: 

The ImposeJob procedure is invoked after references to the merged PostScript® files 450 and the instruction set 
have been placed on the Operands stack. Further, the above-described procedures and variables have been loaded 
into the impositiorxiict dictiorTary. 
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Fig. 28 is a flowchart illustrating the program steps implemented by the ImposeJob procedure according to the 
imposition-on-the-fly procedures of the present invention. A block 652 invokes the EnableVirtualDevice procedure, 
desaibed above in connection with Rg. 23, to set up the showpage operator to support virtual devices. 

A block 654 then retrieves the first file/list pair (containing the name of the merged PostScript® file and the corre- 
sponding entry list with the user procedures, page numbers and operands for the setvirtualdevice procedures for the 
cunrent flat 456) from the instruction set. The file/list pair is stored in an array that was placed on the Operands Stack 
prior to calling the ImposeJob procedure. 

For each file/list pair, a block 656 invokes the ImposeRle procedure, described below, which retrieves each entry 
from the entry list and determines which pages described in the merged PostScript® file 450 should be rendered on the 
flat 456. Assuming more than one file/list pair is contained in the array, the blocks 654 and 656 are inrplemented in a 
loop which individually retrieves each file/list pair from the array and invokes the ImposeFile procedure to process each 
file/list pair 

After every file/list pair from the instruction set has been processed by the InrposeRle procedure, a block 658 sets 
the boolean variable ImageDone to true. ImageDone will be used to instruct the RIP 82 that the imposition job is com- 
plete and the flat 456 can be ejected. The value of ImageDone at this point could be determined by a global variable. 
ImageDone could also be set to true in the user procedure in the last entry of the last instruction set list. 

Next, a block 660 determines whether the showpage operator was redefined to emulate level 2. If so. a block 662 
executes the standard level 1 showpage operator (renamed ''systemdict_shov4)age'') in order to transmit the contents 
of the raster memory 452 to the demand printer 84 for physical rendering of the flat 456. In the level 2 implementation, 
the flat 456 is automatically rendered by the showpage operator when the redefined EridPage procedure returns a 
"true." (See Fig. 20). If the showpage operator was not redefined, a block 664 ends the program. 

The blocks 652-662 of the ImposeJob procedure may be implemented by the following code: 

/ImposeJob % Impose pages from each input file 

impositiondict /Enai^leVirtualDevice get exec 
{ % Call ImposeFile for 

aload pop pop % each file in inscructiion 

* set: 

impositiondicc /ImposeFile gee 
exec 
} forall 

imposiciondici: /ImageDone true put 
impositiondict /syscemdict_showpage 

kjiown { % Did we redefine showpage 

impositiondict /systemdict^showpage 
jet exec %If yes, execute it. 



get 

T if 
} def 



(Blocks 653 and 657 of the ImposeJob procedure, which are implemented only in connection with the optional imposi- 
tion-on-the-fly of the invention, will be described below.) 

The ImposeRle Procedure: 

Fig. 29 illustrates the program steps implemented by the ImposeFile procedure of the imposition-on-the-fly proce- 
dures of the invention. When the ImposeFile procedure is invoked, the ImposeJob procedure has placed a file/list pair 
from the instruction set on the Operands stack. The f Be/list pair contains a list of entries (the "PageLisf*), wherein each 
entry specifies: 

1 ) a first user procedure; 

2) the number of the page to rendered on the flat 456; 

3) the operands to the setvirtualdevice procedure (which generates the virtual [CTM] for properly positioning the 
page on the flat 456); and 

4) a second user procedure (specifying offsets). 

A block 670 sets the variable PageOffset = CurrentPage + PageOffset + 1. CunentPage (representing the number 
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of the next page in the current merged PostScript® file 450 that is to be rendered on the flat 456) is initially 0 and Page- 
Offset (representing the cumulative number of pages from previous files processed) is initially -1 . Therefore, on the first 
pass of the ImposeFile procedure. PageOffset is equal to 0 (indicating that no previous files have been processed). A 
block 672 then uses the pointer Currentlndex to retrieve the first entry from the entry list received from the ImposeJob 
5 procedure. A block 673 then retrieves the page number from the entry and sets Cun-entPage equal to its value. Thus. 
CurrentPage now specifies the number of the first page in the current merged PostScript® file that should be rendered 
on the flat. 

Next, a decision-making block 674 determines whether the first page in the current PostScript® file (page number 
0) should be rendered on the flat by comparing Cun-entPage to 0. If CurrentPage is equal to 0. the first page in the 
10 merged PostScript® file 450 should be imposed and rendered on the flat, and a block 675 executes the first user pro- 
cedure contained in the current entry retrieved by the block 672. Alternatively, it the block 674 determines that the first 
page is not on the flat, a block 676 pops the first user procedure from the retrieved entry from the stack. 

After the block 675 has executed the user procedure or after the block 676 pops the user procedure, a block 678 
executes the setvirtualdevice procedure, which was described in detail above in connection with Fig. 25. The setvirtu- 
15 aldevice procedure sets the virtual [Cru\ and the clipping path according to the operands included in the retrieved 
entry. 

The blocks 670-678 of the ImposeRle procedure may be implemented by the following code: 
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/ImposeFile ( 

impositiondicc begin 

/PageOCfsec CurrentPage PageOffset add 1 add def 
/PageLisc exch def 
/Currentlndex 0 def 

PageList Currentlndex get % get encry 

aload pop pop 
5 -2 roll dup 

/CurrentPage exch def % get page number for 1st 

% page 

0 eg ( V if 1st page is on flat 

exec % execute user procedure 

} ( 

pop V if 1st page is not on 

% flat 

) ifelse * pop user procedure 

setvirtualdevice ' k call setvirtualdevice 



Next, a decision-making block 680 determines whether the first page in the current PostScript® file {page number 
0) should be rendered on the flat by comparing Cun-entPage to 0. If Cun-entPage Is not equal to zero (i.e. the first page 
should not be rendered on the flat), a block 682 invokes a procedure called, for example, "MakeNulI." The MakeNull pro- 
cedure, which is described in detail below in connection with Fig. 30, creates a scaled-down version of the virtual device 
for the next page to be rendered on the flat. The MakeNull procedure will be used to quickly interpret pages included in 
the merged PostScript® file 450 that will not be rendered on the cun-ent flat 456. The block 682 also calls the.redefined 
initclip operator (see Fig. 21). 

After the block 682 executes the MakeNull procedure, or. alternatively, if the block 680 determines that Cun-entPage 
is equal to zero (i.e. the first page should be rendered on the flat), a block 684 sets the variable LastPage equal to the 
page number of the last page in the PostScript® file to be rendered on the fiat. The last page is determined by defining 
Lastlndex as the number of entries in the instruction set minus one. The entries are indexed starting with zero (i.e., 0. 
1.2,3.) such that the last of four entries will be entry number 3. Lastlndex is then used to retrieve the page number from 
the last entry in the entry list, which is stored in the variable LastPage. The block 684 thus determines the number of 
page descriptions in the cun-ent merged PostScript® file 450 that need to be interpreted in order to properly render all 
of the selected pages on the flat 456. 

The blocks 680-684 of the ImposeFile procedure may be implemented by the following code: 
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/CurrentPage 0 ne { % if page is not on flat 

MakeNuil ^ execute MakeNull 

% procedure 

initclip 
} if 

/Lastlndex PageList length 1 s\ab def 
/LastPage PageList Lastlndex get l get def 

A block 686 then opens the current merged PostScript® file 450. if necessary, and defines a file object (i.e. "Th^ 
File") to access the current merged PostScript® file 450. The block 686 then interprets the current merged PostScript 
file 450. which contains various page descriptions, including the selected pages to be rendered on the current flat 456. 
Each page description includes the showpage operator, which will invoke the redefined EndPage and BeginPage pro- 
cedures of the present invention. • ._ x ^ ^ *u 

Preferably the block 686 executes the merged PostScript® file 450 in stopped mode, wh.ch dictates that the exe- 
cution will stop once the last page that needs to be processed for the flat 456 is executed (detemiined by the value of 
LastPage). Once execution is complete, a block 688 flushes and closes the current PostScript® file and a block 690 
returns to the block 654 of the ImposeJob procedure (Fig. 26) to retrieve the next file/list pair.from the instruction set 

The blocks 686-690 of the ImposeFile procedure may be implemented by the following code: 



dup type 1 string type eq { (r) file } if 
dup /ThePile exch def 
25 cvx 
end 

stopped { count 0 eq dup not 

{ pop dup (done with current file) ne } if 
I stop } { pop } ifelse 
impositiondict /TheFile get dup flushfile 
closefile 
} bind def 
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The MakeNull Procedure: 



40 The MakeNull Procedure is invoked by the block 682 of the ImposeFile procedure before processing pages that will 
not be rendered on the current flat 456. The MakeNull Procedure creates a low resolution (scaled<lown) replica of the 
virtual device for the next page to be rendered on the flat This low resolution virtual device allows for fast processing of 
the non-rendered pages. The non-rendered pages are processed using a low resolution replica of the virtual device for 
the nexl page to be rendered on the flat to ensure that any marks generated by the processing do not oven^vrite a por- 

45 tionof the flat 456 that is already imaged. ^ 

The MakeNull procedure creates a low resolution replica of the virtual device by scaling the components of the vir- 
tual [CTM]. Further, the MakeNull procedure positions the scaled-down virtual device in the middle of the original virtual 
device. This ensures that the scaled^iown virtual device will be completely contained within the clipping path defining 

the original virtual device. , ^ ^- *^ 

so As explained earlier, by definition, the virtual [C™] contains the components [a b c d t, ty] and specifies a transfor- 
mation of the coordinates (x. y) in user space to the coordinates (x'. /) in device space as follows: 

X* = ax + cy + 1 X 

55 y' = bx + dy + ty. 

The PostScript® language includes a scale operator which creates a temporary matrix from supplied x and y scale 
factors and concatenates the temporary matrix with the current [CTM]. The scale operator then replaces the current 
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[CTM] with the resultant matrix. 

c h IT^M^* ?f PostScript® scale operator with x and y scale factors (s, and Sy) as operands, the scaled [CTM] = [s^ 
SyC Syd tx ty]. Thus. tHe new transformation from user to device space specified by the scaled [CTM] is given by: 

x- = Sxax + SyCy + t^ (1) 

y' = Sxbx + Sydy + ty. (2) 

The exact scale factors s,, and Sy may vary according to the type of PostScript® RIP 82 used. However a 1 to 1 
ratio between user and device space coordinates leads to significantly faster processing of pages over normal process- 
mg on a high resolution device. Also, the PostScript® nulldevice operator installs a [CTM] with a 1 to 1 ratio of user to 
i?^.®^- ^l^o^S^ scale factors could be tuned for optimal performance on a given Post- 

script RIP 82. It IS assumal that a 1 to 1 ratio between user and device space coordinates will run with reasonable 
efficiency on any PostScript® RIP 82. Thus, the scale factors s, and Sy used by the MakeNull procedure are preferably 
calculated to achieve a 1 to 1 ratio between user and device space as follows. 

To achieve a 1 to 1 ratio between user and device space coordinates with only the scale factors, the unit vector in 
user space from coordinate points (0,0) to (1 .0) and from (0.0) to (0.1) must have unit length in device space. Therefore. 

l(x*(1.0). y'(1.0))-(x'(0.0). y'(0.0))| = 1 (3) 

and 

l(x'(o.i). y(o.i))-(xxo.o). y(o.o))| = i. (4) 

25 From equations (1) and (3). 

|(s^a + t^.s,b + ty)-(t^.ty)| = 1 

|(Sxa.Sj,b)| = l 

((s,a)%(s,b)2)^'2 = 1 

Thus, s, = 1/(a' + b^") ''^ . Similarly, Sy = 1/(c%d^) . 

Fia 30 Illustrates the program steps implemented by the MakeNull procedure. A block 698 first determines and 
h!?^* coordinates of the midpoint of the virtual clipping path. The midpoint (mpx, mpy) is determined 

by first retrieving the corner coordinates of the virtual clipping path, which are stored in the variables ClipllX. ClipurX 
SS. ^!?r : 1^ ""'^^ ^""^""^ calculated by adding the lower left and upper right x-axis corner coor- 

dinates (ClipllX and ClipurX) and dividing by two. Similarly, the y-axis midpoint (mpy) is calculated by adding the y-axis 
corner coordinates (ClipllY and ClipurY) and dividing by two. After the midpoint is calculated, the standard PostScript® 
sp^OTor^nate? ^'^"^""^ "systemdict.transfbrm") is executed to convert the user space coordinates to device 

Next, a block 700 gets the virtual [CTM] which is stored in the variable DefaultMatrix. A block 702 then calculates 
Tnl!^ fectora and Sy as specified above and a block 704 applies the scale factors to the virtual [CTM]. A block 
706 then saves the scaled virtual [CTM] as the new virtual [CTM] in the variable DefaultMatrix. 

A block 708 then sets the midpoint of the scaled clipping path (specified by the new virtual [CTM]) to correspond 
wrth the coordinates of the midpoint of the original clipping path (saved by the block 698). The block 708 determines the 
difference between the saved midpoint coordinates and the new midpoint coordinates and then translates the new coor- 
dinates by that difference. 

The MakeNull procedure may be inplemented by the following code: 
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/MakeNull { 

imposiciondict: begin 

ClipllX ClipurX add 2 div ClillY ClipurY add 

syscemdict^transf orm 
/mpy exch def 



2 div 



/mpx exch def 
DefaulcMacrix 
dup 

dup dup 

dup 0 get dup mul 

exch 1 get dup mul 

add 1 exch div sqrt dup 1.0 gt 

{ pop 1.0 } if exch 
dup 2 get dup mul 
exch 3 get dup mul 
add 1 exch div sqrt dup 1,0 gt 

{ pop 1.0 } if 
l>5atrix scale 

exch Matrix2 concatmatrix ' 
systemdicc^setmatrix 



% calculate 
% midpoint 



% 

V 



compute 
compute 
compute 

compute 
compute 
compute 



c^ 

d^ 



% scale matrix 
save as the new 
virtual default 
matrix 



ClipllX ClipurX add 2 div ClipllY ClipurY 

sy3temdict_transf orm 
/mpy exch mpy sub neg def V translate 
/mpx exch mpx sub neg def * midpoint 

mpx mpy systemdict_idtransform translate 
systemdict_currentmatrix pop 
end 
} bind def 



add 2 div 



The Redefined EndPage Procedure: 

The page descriptions contained in the merged PostScript® lile 450 all include the showpage operator, which will 
invoke the redefined EndPage and BeginPage procedures. 

The redefined EndPage procedure updates the CurrentPage variable, which represents the nuniber o1 the next 
page in the merged PostScript® file 450 that should be imposed and rendered on the flat. The redefined EndPage pro- 
cedure also calls the setvirtualdevice and MakeNull procedures for the pages to be interpreted. 

Fig. 31 is a flowchart illustrating the program steps implemented by the redefined EndPage procedure. A block 710 
determines whether the EndPage procedure was called by the showpage operator by determining whether the reason 
code is 0. A block 712 compares CurrentPage plus PageOffset to PageCount to determine, whether the current page in 
the PostScript® file should be imposed and rendered on the flat 456. 

Assuming both of the blocks 710 and 71 2 are true, a block 71 3 set ups the default environment by calling the stand- 
ard initgraphics operator (now renamed "systenxiictjnitgraphics''). The block 713 then retrieves and executes the sec- 
ond user procedure (containing, for example, the offset instructions) from the current entry. If the second user 
procedure contains offset instructions, the PostScript® file will be repositioned to the start of the next page to be 
included in the book, thereby skipping processing of any irrelevant pages. If the second user procedure contains other 
instructions (such as barcodes, watermarks, etc.). they will also be executed. 

Next, a block 714 increments the pointer Currentlndex. which will be used to retrieve the next entry from the entry 
list (PageList). The decision-making block 716 then determines whether there is another entry in the instruction set by 
comparing Currentlndex to Lastlndex. 

If Cun-entlndex is less than or equal to Lastlndex. a block 71 8 resets the graphics state to its system default value 
by calling the standard PostScript® initgraphics operator (now renamed "systemdictjnitgraphicsl. A block 720 then 
uses Currentlndex to retrieve the next entry in the entry list to place the operands for the setvirtualdevice procedure on 
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the Operands stack and a block 722 invokes the setvirtualdevice procedure. 

A block 724 then sets CurrentPage equal to the number of the page from the retrieved entry. CurrentPage is now 
updated to contain the number of the next page from the merged PostScript® file 450 that should be imposed and ren- 
dered on the flat 455. 

Next, a block 726 invokes the MakeNull procedure to set up the low resolution virtual device for processing of non- 
rendered pages. The MakeNull procedure is called because it Is assumed that the next page in the merged PostScript® 
f (le 450 will not be rendered on the flat 456. (If the next page should be rendered on the flat, the redefined BeginPage 
procedure, described in detail below, will establish the virtual device for thai page). A block 728 then removes the user 
procedure (which is contained in the retrieved entry) from the Operands Stack. 

If any of the blocks 710. 712 or 716 are false, or after the block 728 pops the user procedure, a block 730 places 
the value of the variable ImageDone on the stack. If ImageDone has the value of true, indicating that the flat is com- 
pleted. the calling of the EndPage procedure (i.e.. by the showpage operator or for new device activation) will automat- 
ically transfer the contents of the raster memory 452 to the demand printer 84 to physically render the selected paqes 
on the flat 456. (See Fig. 19). 

A block 732 then resets ImageDone to false to specify that the flat is not conpleted and the contents of the raster 
memory 452 will not yet be transferred to the demand printer 84 for physical rendering. 
The redefined EndPage procedure may be implemented by the following code: 

/EndPage { 

impositiondict begin 

0 eq 

excfa 

CurrencPage PageOftset: add eq 
and { 

sys cemdi c t_ini tgraphics 
PageLisc Currentlndex get 
5 get exec 

/Currentlndex Currentlndex 1 add def 
Currentlndex Lastlndex le { 

systemdict_ini tgraphics 

PageLisc Currentlndex get 

aload pop 

setvirtualdevice 

/CurrentPage exch def 

MakeNull 

pop 

} if 
ImageDone 

/ImageDone false def 
end 
} bind def 



The Redefined BeginPage Procedure: 



Fig. 32 is a flowchart illustrating the program steps implemented by the redefined BeginPage procedure. A block 
740 first calls the redefined initmatrix operator to set the virtual [CTU]. 

Referring also to Hg. 20. the BeginPage procedure receives PageCount as an operand from the showpage opera- 
tor. A deasion-making block 742 compares Cun^entPage (which was updated by the block 724 of the redefined End- 
Page procedure of Fig. 31) to PageCount CurrentPage contains the number of the next page in the PostScript® file to 
be rendered on the flat 456. Thus, if CurrentPage and PageCount are equal, the current page in the merged Post- 
Script file 450 should be imposed and rendered on the flat 456 and a block 744 retrieves the next entry (containing 
the user procedures, page number and setvirtualdevice operands) from the entry list 

A block 745 then executes the us& procedure from the retrieved entry and a block 746 invokes the setvirtualdevice 
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procedure to set up the virtual [CTM] and clipping path for the virtual device (see Fig. 27). A block 748 then pops the 
page number from the retrieved entry. 

Next, a block 750 "blanks out" the virtual page by coloring the area inside of the clipping path white. This is neces- 
sary to erase any stray marks that may have been placed on the page when the non-rendered pages were processed 
using the MakeNull procedure. 

Alternatively, if the block 742 determines that the next page in the merged PostScript® file 450 should not be ren- 
dered on the flat (I.e. CurrentPage is not equal to PageCount). a decision-making block 752 corrpares PageCount to 
LastPage plus PageOffset. If PageCount is greater than LastPage plus PageOffset. subsequent pages in the Post- 
Script® file do not need to be interpreted because they are beyond the last page that should be rendered on the flat 
456. Thus, a block 754 stops the execution of the merged PostScript® file 450. As explained earlier, the ImposeFile pro- 
cedure executes the merged PostScript® file 450 in stopped context. In order to distinguish between the expected stop 
in the block 754 and an unexpected stop caused, for example, by a PostSaipt® error, the string "done with current file" 
is generated by the block 754 of the redefined BeginPage procedure. Referring also to Fig. 27. the block 386 of the 
ImposeFile procedure checks for the "done with current file" string to determine when to proceed to the block 688 to 
flush and close the merged PostScript® file 450. 

Alternatively, if the block 752 determines that PageCount is less than pr equal to LastPage plus PageOffset (i e. the 
current page is before the last page to be rendered on the flat), a block 756 calls the redefined initclip operator to reset 
the virtual clipping path. (See Fig. 20). 

The redefined BeginPage procedure may be implemented by the following code: 

/BeginPage { 

inicmacrix 

imposiciondicc begin 
dup 

CurrencPage PageOffsec add eq { % page on flat 
pop % pop PageCount: 

PageLisc Currentilndex get % gee entry 

aload pop 
5 -1 roll 

exec % execute user procedure 

setvirtualdevice 

pop % pop the page number 

clippach 1 setgray fill % blank out virtual 

% page 



0 setgray newpath 

} bind { % page not on 

% flat 

LastPage PageOffset add gt { 

end (done witii current file) atop } if 
initclip 
} ifelse 

end 
} bind def 



The ImageOone Variable: 

As explained earlier, the variable ImageDone is a boolean variable used to indicate when all the pages for the cur- 
rent flat 456 have been interpreted and painted into the raster memory 452 such that the flat 456 can be physically ren- 
dered by the demand printer 84. ImageDone is initially and nonnally set to false, indicating that the current flat 456 has 
not yet been completed. However, referring to Rg. 26, after all the file/list pairs from the instruction set have been proc- 
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^sed by the ImposeJob procedure, the block 658 sets ImageDone to true to indicate that the flat is completed. Also, 
the user procedure contained in the last entry in a file/list pair in the instruction set could include an instruction to set 
ImageDone to true to specify that the current flat is conrpleted. 

The ImageDone variable is used by the redefined EndPage procedure. Referring to Figs. 20 and 31 . the block 730 
of the redefined EndPage procedure returns the value of ImageDone to the block 502 of the showpage operator If 
ImageDone is true, the block 504 transmits the contents of the raster memory to the demand printer to render the cur- 
rent flat. 

The ImageDone variable may be utilized to allow for multiple flats to be rendered by a single file/list pair in the 
instruction set (see Appendix I sample instruction set). 

The Showdevice Procedure: 

The imposition-on-the-f ly procedures may Include an additional procedure, called, for example, "showdevice " 
which uses the ImageDone variable to allow a user to render the flat at any time The showdevice procedure sets Image- 
Done to true and then calls the showpage operator, which will invoke the redefined EndPage procedure and render the 
current flat, as desaibed above. 

The showdevice procedure may be implemented by the following code: 

/ showdevice { 

imposiciondicT: /ImageDone crue put: 
showpage 

} def 



The showdevice procedure will normally be used when a user implements the setvirtualdevice (and related) proce- 
dures in a non-imposition application in which tfie ImposeJob and ImposeFile procedures are eliminated For example 
file 2^^^""^® procedure could be implemented to render any selected page(s) contained in the merged PostScript® 

Optional Imposition-on-the-Rv Procedures: 

Optionally, additional procedures may be included in the imposition-on-the-fly procedures which will allow the 
proper imposition of page descriptions using the PostSaipt® save and restore operators. 

The PostSaipt® save operator takes a "snapshot^ of the state of virtual memory which stores all values of com- 
posite objects, such as sti-ings and arrays. Many of the variables used by the imposition-on-the-fly procedures of the 
present invention are stored in virtual memory. The save operator also saves the current graphics state by pushing a 
copy of the cun-ent graphics state onto the Graphics State Stack. The PostScript® restore operator restores the virtual 
memory and the current graphics state to tiie state at the time the corresponding save operator was executed. 

Jie PostScript® gsave operator pushes a copy of the current graphics state onto the Graphics State Stack and the 
PostScript grestore operator pops tine saved graphics state from the Graphics State Stack and restores it as the cur- 
rent graphics state. The PostScript® grestoreall operator restores either the bottom-most graphics state stored on the 
Graphics State Stack or the first graphics state that was stored by the save operator (as opposed to the gsave operator) 
The elements of the current graphics state affected by these operators include the current [CTM]. clipping patii and cur- 
rent path. However, tiney do not affect the contents of the raster memory 452. 

The PostScript® save and restore operators may adversely affect the imposition-on-the-fly procedures of the 
presem invention, as well as on other imposition methods. The problem arises if a page description in the merged Post- 
Script file 450 invokes a save operator, which will save the [CTM] that specifies the desired position for that page on 
rn^>.r'^®' ^ ^"*^sequent page description invokes a restore operator, the [CTM] for the prior page will replace the 
[CTM] for the subsequent page. Thus, the subsequent page will be incorrectly positioned on the flat 456 

To overcome this problem, two new procedures (Vsave and Vrestore) are used in connection with the above- 
described procedures. The Vsave and Vrestore procedures will be used to redefine the PostScript® save and restore 
operators such that they do not interfere witii the other imposition-on-the-fly procedures of the present invention. 

The Vsave Procedure: 

Generally, the Vsave procedure appends tiie page size components (PageX and PageY) and the virtual [CTM] 
components (which define the virtual device) to the current path, which will be saved by the PostScript® save operator. 
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Later, the Vrestore procedure will retrieve these components, remove them from the current path, and use them to gen- 
erate the correct clipping path, page orientation and [CTTVI] for the restored page. 

Fig. 33 is a flowchart illustrating the program steps implemented by the optional Vsave procedure. A blod^ 800 
saves a copy of the current [CTM] and then a block 801 sets the [CTM] equal to an identity matrix ([1 00 1 0 0]). 

5 The identity matrix is used because all points used to describe the cun-ent path are specified in user space coordi- 

nates. However, at the time a PostScript® program enters a point into the current path, each coordinate is transformed 
into device space according to the [CTt^. Thus, the identity matrix will be used when adding the components to the cur- 
rent path to avoid any round off errors that may occur in this conversion from user space to device apace. 

A decision-making block 802 then determines whether a currentpoint is defined, a currentpoint is defined, a block 

JO 804 sets the variable pi equal to the current path. This may be accomplished by invoking the previously defined Make- 
Path procedure, which creates a description of the current path In the current coordinate system. (The MakePath pro- 
cedure was described above in connection with the block 524 of the redefined inrtclip operator of Fig. 20). 

A block 806 then defines a variable called, for example, "f irstop" to be the PostScript® lineto operator. By definition, 
the PostScript® lineto operator adds a straight line segment to the current path by connecting the previous current point 

15 to the new one. 

Alternatively, if the block 802 determines that no currentpoint exists, a block 808 sets p1 equal to an empty path. A 
block 810 then defines firstop to be the PostScript® moveto operator, which establishes a new currentpoint. 

After firstop is defined by either the block 806 or the block 81 0. a block 812 creates an "unlimited*" tx)unding box for 
the current path. A bounding box, which is nornnally established by the PostScript® setbbox operator, defines the area 

20 in which the current path coordinates must fall. The operands to the setbbox operator are the user space coordinates 
of the lower-left and upper-right corners of the bounding box. Since the page size and [CTM] components will be added 
to the current path during the Vsave procedure, the bounding box must be set large enough to encompass the "points" 
defined by those components. Thus, a previously defined procedure called, for example, "SetBigBBox," may be invoked 
to set the bounding box to be the largest possible. The SetBigBBox procedure may be implemented by the following 

25 code: 

/SetBigBBox /secbbox where { 
-pop { 

-2147483648 -2147483648 2147483648 2147483648 
secbbox 
} bind def 

( 

} def 
•} ifelse 



} 



After the large bounding box is set, a block 814 invokes the firstop operator (defined by the block 806 or the block 
40 810) to append the page size components (PageX and PageY) to the current path. Next, a block 818 appends the vir- 
tual [CTM] components (stored in the variable DefaultMatrix) to the current path. A block 820 then replaces the identity 
[CTpiq with the [CTM] that was saved by the block 800. 

The Vsave procedure may be implemented by the following code: 
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10 



15 



20 



25 



/Vsave { 

Matrix syscemdicc^currentmacrix 
dup 

Idencity sysceindict:_setmacrix 
{ currencpbinc) stopped { 
/pi ( } def 

/firscop { cnoveto } def 

pop pop 

/pi Ma}cePaCh def 
/firstop { lineto } def 
} ifelse 

SetBigBBox 

PageX PageY firsrop 

Def aulCMacrix 
aload pop 
lineco 



* [CTMl = 
% idencity 

% no current 
% point 

k define empty 
% path 

% current point 

* create real 
% path 



% append page 



% size 



% append [CTM] 



30 



lineto 
lineto 

systemdict_setmatrix 
} bind def 
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The Vrestore Procedure: 

The Vrestore procedure retrieves the page size and virtual [CTM] components (which defined the virtual device) 
40 appended to the current path by the Vsave procedure and„uses them to generate the correct clipping path, page orien- 
tation and virtual [CTM] for the restored page. 

Fig, 34 is a flowchart illustrating the program steps implemented by the Vrestore procedure. A block 830 saves the 
current [CTM] and a block 832 then sets the [CTM] to an identity matrix. As in the Vsave procedure, the use of the iden- 
tity [CTM] will avoid any round off errors when transforming coordinates from user space to device space in the current 
45 path. 

A block 834 then retrieves the elements of the current path by calling the PostScript® pathforall operator, which 
pushes the user space coordinates of each path element onto the Operands stack. The retrieved elements will include 
the page size and virtual [CTM] components that were appended to the path by the Vsave procedure. A block 836 then 
performs various stack manipulation operations to place the page size and virtual [CTM] connponents on top of the 

50 stack. The block 836 then stores the componerrls in variables called, for exampte, "ResDefauttMatrix," "ResPageX" and 
"ResPageY." which represent the page size and virtual [CTM] at the time that the PostSaipt® save operator was called. 

Next, a decision-making block 838 compares the ResDefaultMatrix (at time of save) to the current virtual [CTM] (at 
time of restore), which is saved in the variable DefaultMatrix. The equivalency of the matrices may be easily determined 
by using a previously defined utility routine, called, for example, "EqualMatrix." which performs a component-by-com- 

55 ponent comparison of the two matrices, allowing for a slight floating point round-off error. If the two matrices are equiv- 
alent, the EqualMatrix routine returns a true on the stack; if they are not equivalent, the EqualMatrix routine returns a 
false. The EqualMatrix routine may be inplemented by the following code: 
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/EqualMacrix { 
cnie 

impositiondicc begin 
5 /Counc 0 def 

6 { 1 index Counc gen 3 index Count: get 

eq 

sub abs -0001 Ic and 
/Counc Counc 1 add def } repeat 
10 3 1 roll pop pop 

end 
} bind def 



15 



20 



If the block 838 determines that the restored [CTM] and current [CTM] are not equivalent it is assumed that the 
save operator was called during interpretation of one page and the restore ^P«^^^°^^^^^^^ 

another page. A block 840 then sets the [CTM] back to the value saved by the block 830. Next, a block 842 cal^ p1 
which comains the current path at the time the save operator was called. The block 842 then removes the page size 
and [CTM] components that were added to the current path and sets pi equal to the remaining path elements. 
The blocks 830-842 of the Vrestore procedure may be implemented by the following code; 



/Vrescore { 

Macrix systemdicc_currencmacrix 
25 Identity systemdict_setmatrix 

mark 

{} {} {) {} pachforall 
6 2 roll 
4 2 roll 
30 mark 7 1 roll 

] /ResDef aultMacrix exch def 
/ResPageY exch def 
/ResPageX exch def 

clearcomark . ^ ^ • 

DefaultMatrix ResDef aulcMatrix EqualMatrix not 

^ '3ystemdict_3etmatrix 
/pi mark 

MakePath aload pop 
40 pop pop pop 

pop pop pop 
pop pop pop 
pop pop pop 
1 cvx.def 
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Next, a decision-making block 844 determines the orientation of the restored page l^y compar.ng ResPageX to 
ResPageY. If ResPageX is greater than ResPageY, a variable called ResPortrait is set to false to indicate a landscape 
orient^ion. Alternatively, if ResPageX is less than ResPageY. the variable ResPortrait is set to *° ""J;^^*!,^ P°^^^' 
orientation. The block 844 then compares ResPortrait (the restored page orientation to Portrait (the saved Pase onen- 
tation). If the page orientation has changed (ResPortrait and Portrait are not equal), a block 846 calls the SetPortrait 
procedure to change the orientation of the device. (See Hgs. 25 and 26A&B). 

The blocks 844 and 846 of the Vrestore procedure may be implemented by the following code: 
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ResPageX ResPageY gc { 

/ResPorcraic false def 

/ResPorcraic crue def 
} ifelse 
ResPorcraic Porcraic ne { 
SecPorcraic 
} if 



848 saveMhTp^uS^^^^^^^ T °' ""^^ ^ the orientation, a block 

virtu^ rc™?t^rrn?^'"'r' determining the accumulation of operations applied on the restored 

reSorSJrom^lT ^ ^" ^ "'''^ considered the result of the restored virtual [CTM] (i.e., the virtual [C™i 
^s^ored from the save operator) concatenated with an operations matrix The block 850 then calculates the ollLtinnJ 

[current CTM] = [operations] [restored virtual CTM]. 
Further, the block 850 performs the following operations: 

[operations] = [current CTM) [restored virtual CTM] ; 



and 



[new CTM] = [operations] [current virtual CTM]. 
The blocks 848 and 850 of the Vrestore procedure may be implemented by the fon^^ 

/i^'^S^u^r, .... ^ generate clip path procedures 
/cl MakePath def 

Matrix syatemdict_ciirrentmacrix % calculate new 
ReaDef aultMatrix % [CTM] 

Matrix2 invertmatrix 
MatrixB concatmatrix 
DefaulcMatrix Matrix4 concatitiatrix 
sy s t emd i c t _s e tma t r ix 

n flT^fl^^^^'L^^^^^^^^ "^'PP'^^ path (saved in cl) and a block 854 regenerates the current oath fsaved 
wi^g S^iT '"^"^'^ ^^''^ f^"^^- ^-^'ocks 852 and' 854 may be inillC bT^ 



syacemdict^initclip 

nswpath 

cl 

clip newDath 
pl 
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Alternatively, if the block 838 determines that the restored virtual [CTM] is equivalent to the current virtual [CTM] 
(i.e.. the save and restore operators were called on the same page), a block 856 simply removes the page size arxi vir- 
tual [CTM] componerrts from the current path. A block 858 then restores the current path and a block 860 sets the [CTM] 
back to the value saved by the block 830. 

The blocks 856-860 may be implemented by the following code: 

{ 

/pi marlc 

MaJcePach aload pop 

pop pop pop 

pop pop pop 

pop pop pop 

pop pop pop 

] cvx def 

newpath 



Pl 

syscemdict^setmatrix 
} ifelse 
} bind def 



The Redefined PostScript® Save Operators: 

The PostSaipt® save operators (which include save and gsave) are redefined to invoke the Vsave procedure. 
Before the operators are redefined, however, they are renamed f systemdict_operator," for example) because their nor- 
mal operation is defined in the systenrxjict dictionary. The save operators may be renamed by the following code: 

/systenxJict_save systemdict /save get def 
/systemdict_gsave systenxiict /gsave get def 

The PostScript® save and gsave operators are then redefined. Fig. 35 is a flowchart illustratng the program steps 
implemented to redefine the PostScript® save operators. A block 872 first invokes the Vsave procedure, which was 
described above in connection with Fig. 33. The Vsave procedure saves the current path in pi and then appends the 
page size and virtual [CTM] components to the current path. 

A block 874 then invokes the standard PostScript® save (or gsave) operator (now renamed "systemdict_save" or 
"systemdict_gsave''). The save operator performs its standard function of saving the current state of virtual memory and 
the current graphics state, including the current path (which now includes the page size and virtual [CTM] components). 
The gsave operator performs its standard function of saving the current graphics state. 

Next, a block 876 sets the [CTM] to an identity matrix. As before, this will eliminate any round off errors in. the cur- 
rent path. A block 878 then restores the current path to the path stored in p1 (the path without the added page size and 
virtual [CTM] components) and a block 880 restores the [CTM] back to the virtual [CTM]. 

The blocks 870 - 880 for redefining the PostScript® save operator may be implemented by the following code: 
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/save { 

imp OS i t i and i c t beg in 
Vsave 

sy s c emd i c c_save 

Identity systemdicc__setmatrix 

Tiev/path 

pl 

exc h s y s t emd i c t_s e t ma t r ix 
end 
} bind def 



Similarly, the PostScript® gsave operator may be redefined by implementing the follo>Anng code: 

/gsave { 

impoaitiondict begin 
Vsave 

sy s t emd i c t _gs ave 

Identity systemdict_setmatrix 

newpath 

pl 

s y s t emdi c t _s e tma t r ix 
end 
} bind def 



The Redefined PostScript® Restore Operators: 

The PostScript® restore operator must also be renamed and redefined to invoke the Vrestore procedure. Like the 
save operators, the restore operator is renamed, for example. ''systemdict_restore,*' by the following code: 

/systemdict_restore systenxJict /restore get def 

Because the PostScript® save and restore operators affect the contents of virtual memory and the graphics state, 
the values of many variables used during the imposition and setvirtuatdevice procedures may be inadvertently altered 
by the use of these operators. However, simple values stored on the Operands Stack are not affected. Therefore, the 
PostScript® restore operator is redefined to protect the values of the variables stored in virtual memory by saving them 
on the Operands Stack before calling the standard PostScript® restore operator. 

Fig. 36 is a flowchart illustrating the program steps implemented by the redefined restore operator. A block 892 
places the values of all the imposition variables stored in virtual memory on the Operands stack so their values are not 
overwritten by the restore operator. Then, a block 894 calls the standard restore operator (now renamed "systemdict- 
restore"). A block 896 then puts the values of the variables on the Operands stack back to their pre-restore values. 
Lastly, a block 898 invokes the Vrestore procedure. 

The blocks 892-898 of the redefined restore operator may be implemented by the following code: 
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/restore { 

imposiciondicc begin 

ImageDone % puc variables on stacJc 

Current Index 

Current Page 

PageCount 

Portrait 

PageX 

PageY 

ClipllX 

ClipllY 

ClipurX 

ClipurY 

mark Def aulcMatrix k put [CTM] components on . 

a load pop % stack 

19 -1 roll 

systemdict_restore % call standard restore operator 
] 

/Def aultMatrix exch def % replace variables with 
/ClipurY exch def % pre-rescore values 



/ClipurX exch def 
/ClipllY exch def 
/ClipllX exch def 
/PageY exch def 
/PageX exch def 
/Portrait exch def 
/PageCount exch def 
/CurrentPage exch def 
/Currenclndex exch def 
/ImageDone exch def 

Vrestore * invoke Vrestore procedure 

end 
) bind def 



The Redefined PostScript® grestore Operators: 

The standard PostScript® grestore or grestoreall operators, are renamed, for example, "systemdict.operator." This 
may be implemented by the following code: 

/systemdict_grestore systemdict ygrestore get def 
/systemdict_grestoreall systemdict /grestoreall get def 

Because the PostScript® grestore and grestoreall operators affect only the graphics state, it is not necessary to 
protect the values of any variable stored in virtual memory. Thus, the grestore or grestoreall operators are more simply 
redefined. 

Fig. 37 is a flowchart illustrating the program steps Implemented by the redefined PostScript® grestore and gresto- • 
reall operators. A block 902 invokes the renamed standard grestore or grestoreall operator and then a block 904 invokes 
the Vrestore procedure, which will calculate the correct [CTM] and correct the page orientation and clipping path. 
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The blcx:ks 902-904 for redefining the PostScript® grestore operator may be implemented by the following code: 

/grestiore { 

impositiondict begin 

sysremdict^grestore 

Vrescore 

end 
} bind def 



Similarly, the grestoreall operator may be redefined by implementing by the following code: 

/gre3Coreall { 

imposiciondicc begin 

syst:erTidicc_grescoreall 

Vrescore 

end 

} bind def 



The PostScript® Level 2 Gstate Operators: 

Level 2 PostScript® implementations support the following three additional operators that affect the current graph- 
ics state (and therefore the [CTM]) and that may Interfere with the imposition procedures of the present invention: 
gstate. currentgstate and setgstate. The PostSaipt® gstate operator creates a new graphics state object (whose initial 
value is the current graphic state) and pushes it on the Operand stack. The PostScript® cun-entgstate operator replaces 
the value of the gstate object with the current graphics state. The PostScript® setgstate operator replaces the current 
graphics state with the value of the gstate object. 

Similarly to the gsave and grestore operators described above, the gstate operators are renamed and redefined to 
Invoke the Vsave the Vrestore procedures. The gstate operators may be renamed by the following code: 

/gscace where { % is this level 2? 

pop 

/syscemdict:_gscat:e systemdicc /gscat:e geC def 
/syscemdict_secgscate systemdicc: /setigatate gee 



def 



/systemdict^currentigstace systemdicc 
/currentgstate get def 

} if 



Similar to the redefined gsave operator described above in connection with Fig. 35, the gstate and currentgstate 
operators are redefined to first invoke the Vsave procedure and then to call the renamed standard gstate or cur- 
rentgstate operator. The redefined operators then restore the current path without the page size and [CTM] components 
and reset the virtual [CTM]. 

Also, like the redefined grestore operator described above in connection with Fig. 37, the setgstate operator is rede- 
fined to first call the renamed setgstate operator and then to invoke the Vrestore procedure. 
The PostScript® level 2 gstate operators may be redefined by the following code: 
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/gscate where { % is this level 2? 

pop 

/gscace ( ?r redefine gstate operacor 

imposiciondict: begin % (like gsave operator) 
Vsave 

syscemdicc_^gscate 

Identity systeindict^setmacrix 

newpach • 

pi . ■ - 

exch systemdict^secmatrix 
end 

} bind def 

/currentgscace { V redefine currengstate operacor 

imposiciondict begin % (like gsave 

V operator) 

Vsave 

systemdict_currencgstate 
Identity systemdict_setmatrix 



newpath 
Pl 

exch syscemdict_secmatrix 
end 

} bind def 

/setgstate { V redefine setgsrace operator 

impositiondicc begin % (like grescore 

% operator) 

systemdict_setgstace 

Vrescore 

end 

} bind def 

} if 



These optional procedures are used when it is anticipated that the page descriptions in the merged PostScript® file 
450 may include a save operator in one page description and a restore operator in a subsequent page description. If 
the optional procedures are used, a slight modification should be made to the setvirtualdevice procedure, described 
above in connection with Fig. 27. Referring to Fig. 27, an additional block 633 invokes the redefined save operator and 
then pops the save object from the Operands Stack after the block 632 invokes the EnableVirtualDe/ice procedure. 
This is necessary because the grestore and grestoreall operators can be called without a corresponding save or gsave 
operator. If grestore is called without a gsave operator, it restores the graphics state from the top of the graphics state 
stack. If grestoreall is called without a gsave or save operator, it restores either the graphics state from the bottom of 
the graphics state stack or the graphics state saved by the last save operator If the topmost save object was created 
prior to the redefinition of the save operator, the saved current path will not include the additions of the page size and 
[CTM] components and. therefore, will not operate properly with the redefined grestore and grestorall operators. Thus, 
invoking the redefined gave operator at the block 633 of the setvirtualdevice procedure ensures that the grestore and 
grestoreall operators will always restore a saved graphics state connpatible with the present invention. 

The blocks 630-633 of the setvirtualdevice procedure may be implemented by the following code: VirtualDeviceEn- 
abled not {Enable Virtual Device save pop} rf 

Also, in some PostScript® applications, interpreting different PostScript® files consecutively may interfere with the 
operation of the invention. For example, two different PostScript® files may use the same name for variables with dif- 
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ferent definitions. If the second PostSaipt® file interpreted does not explicitly initialize the variable, the definition of the 
variable from the first PostScript® file will be used, interfering with proper interpretation of the second PostScript® file. 
To overcome this problem, the ImposeJob procedure (Fig. 28) may be altered. 

Referring to Fig. 28, blocks 653 and 657 are added to the ImposeJob procedure to save the state of virtual memory 
(which includes many variable definitions) before retrieving a file/list pair from the instruction set and restoring that 
saved state before retrieving the next f iMist pair. Specifically, the block 653 executes the redefined save operator and 
stores the saved state in a variable called, for example, "SavedState." The blocks 654 and 656 then retrieve a file/list 
pair from the Instruction set and invoke the^ ImposeFile procedure to process the file/list pair, as described above. How- 
ever, after the ImposeFile procedure finishes processing each entry in the file/list pair, the block 657 retrieves the saved 
state stored in the variable SavedState and executes the redefined restore operator to restore that state. The block 657 
thus initializes the virtual memory before the block 654 retrieves the next file/list pair from the instruction set. 

The blocks 650-662 of the InnposeJob procedure incorporating the blocks 653 and 657 may be implemented by the 
following code: 



/ImposeJob % Impose pages from each input 

V file 

{ 

impositiondicc /EnctbleVircualDevice get exec 
aload pop pop 

impositiondict /SavedState 

save pun % save state 

imposiciondicc /ImposeFile 

gee %• call ImposeFile for each 

e^ec % file in instnaction set 

%• cleardictstacJc 

clear 

impositiondict /SavedScace get 

restore % restore saved state 

} forall 

impositiondict /ImageDone true put 
imposiciondict /systemdict_showpage 
known ( % Did we redefine showpage 

impositiondict /systemdict_showpage 



et exec \ If yes. execute it. 



) def 



n 



f 



Further, as explained earlier, for compatibility with the optional procedures, the PostScript® erasepage operator is 
redefined by calling the systemdictjgsave and grestore operators. All of the remaining imposition-on-the-f ly procedures 
are compatible with the optional procedures. 

Numerous modifications and alternative embodiments of the invention will be apparent to those skilled in the art in 
view of the foregoing description. Accordingly, this description is to be construed as illustrative only and is for the pur- 
pose of teaching those skilled in the art the best mode of carrying out the invention. The details may be varied substan- 
tially without departing from the spirit of the invention, and the exclusive use of all modifications which are within the 
scope of the appended claims is reserved. 
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Claims 

30 

1 . An apparatus for controlling a display device, comprising: 

first means for developing first and second sets of template data representing associated first and second tem- 
plate pages, respectively, each set of template data having master data representing fixed information to be 
35 displayed and area data representing an area of a page in which variable information is to be displayed; 

second means for developing a database having a number of entries each of which represents variable irrfor- 
mation; and 

means responsive to the first and second developing means for causing the display device to display the first 
and second template pages with selected variable information. 

40 

2. The apparatus of daim 1 , wherein the causing means includes means for converting the sets of template data and 
the database into commands for the display device specifying sequence and content of page display. 

3. The apparatus of claim 2, wherein the converting means includes means for separating the sets of template data 
45 into master files containing master data and intermediate variable page files having area data. 

4. The apparatus of daim 3, wherein the converting means further includes means responsive to the database and 
the intermediate variable page files for deriving final variable page files having content data representing variable 
Information. 

so 

5. The apparatus of claim 4, wherein the converting means further includes third means for developing the commands 
from the master page files and the final variable page files. 

6. The apparatus of claim 4, wherein at least one of the final variable page flies indudes text data representing text to 
55 be displayed on a page and wherein the deriving means includes means for composing the text data. 

7. The apparatus of claim 1 , wherein auxiliary production devices are cotpled to the causing means and wherein the 
datat^ase includes control information for controlling at least one of the display device and the auxiliary production 
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devices. 

8. The appDaratus of claim 1 , wherein the display device is located remotely from the causing means and further 
including means for transmitting data representing at least one of the first and second template pages with the 
selected variable information over the Internet. 

9. The apparatus of claim 1, wherein the display device is located remotely from the causing means and further 
including means for transmitting data representing at least one of the first and second tenplate pages with the 
selected variable information over an intranet. 

10. The apparatus of claim 1, wherein the display device is located remotely from the causing means and further 
including means for transmitting data representing at least one of the first and second template paged with the 
selected variable information over a computer network. 

1 1 . The apparatus of daim 1 , wherein the display device is a demand printer for printing data representing at least one 
of the first and second template pages with the selected variable information into a book. 

12. A method of controlling a display device, the method comprising the steps of: 

developing first and second sets of template data representing associated first and second template pages, 
respectively, each set of template data having master data representing fixed information and area data repre- 
senting an area of a page for variable information; 

developing a database having a numt>er of entries each of which represents variable Information; and 
causing the display device to display the first and second template pages with selected variable information. 

13. The method of claim 1 2. wherein the step of causing includes the step of converting the sets of template data and 
the database into commands for the display device specifying sequence and content of page display. 

14. The method of claim 13, wherein the step of converting includes the step of separating the sets of template data 
into master files containing master data and intermediate variable page files having area data. 

15. The method of claim 1 4, wherein the step of converting further includes the step of deriving final variable page files 
responsive to the database and the intermediate variable page files wherein the final variable page files include 
content data representing variable information. 

16. The method of claim 1 5. wherein the step of converting further includes the step of developing the commands from 
the master page files and the final variable page files. 

. 17. The method of claim 15, wherein at least one of the final variable page files includes text data representing text to 
be displayed on a page and wherein the step of deriving includes the step of composing the text data. 

18. The method of claim 12, wherein auxiliary production devices are coupled to the display device and including the 
further step of storing control information in the database wherein the control information controls at least one of 
the display device and the auxiliary production devices. 

1 9. The method of claim 12, Including the further step of transmitting data representing at least one of the first and sec- 
ond template pages with the selected variable information to a remote location over the Internet. 

20. The method of claim 12. including the further step of transmitting data representing at least one of the first and sec- 
ond template pages with the selected variable information to a remote location over an intranet. 

21 . The method of claim 12. including the further step of transmitting data representing at least one of the first and sec- 
ond template pages with the selected variable information to a remote location over a computer netvvork. 

22. The method of claim 12. including the further step of transmitting data representing at least one of the first and sec- 
ond template pages with the selected variat^le information to a demand printer for printing. 

.23. A method for assembling pages for reproduction, comprising the steps of: 
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(A) generating a master page description language (PDL) file containing page descriptions of master pages 
with fixed information; 

(B) generating a variable PDL file containing page descriptions of variable pages with variable information; 

(C) Ripping the master and variable page descriptions in conjunction with imposition-on-the-fly procedures 
which impose the master and variable pages into a book format; and 

(D) transmitting the imposed master and variable pages to a display device. 

24. The method of claim 23. further comprising the step of merging the master and variable PDL files before RIPping 
the page descriptions. 

25. The method of claim 23. further comprising the step of generating an instruction set specifying selected pages from 
the master and variable PDL files to be imposed. 

26. The method of claim 25. wherein the instruction set further specifies how the selected pages should be positioned 
on the display device. 

27. The method of claim 25, wherein RIPping the page descriptions in conjunction with the imposition-on-the-fly pro- 
cedures comprises the steps of: 

t) if a page is a selected page. 

a) defining a virtual device as the display device for the selected page, wherein the virtual device specifies 
an area in a raster memory for positioning the selected page on the display device; and 

b) interpreting the selected page; and 

ii) if the current page is not a selected page. 

a) determining a next page in the sequence of page descriptions that is a selected page to be rendered on 
the fiat; 

b) defining the virtual device for the next selected page as the output device for the non-selected page: and 

c) interpreting the non-selected page. 

28. The method of claim 27. wherein RIPping the page descriptions in conjunction with the imposition-on-the-fly pro- 
cedures further comprises the step of skipping to the page description of the next selected page in the PDL file. 

29. The method of claim 23. wherein the display device comprises a demand printer. 

30. The method of claim 23. wherein the display device comprises a computer network. 

31 . A method tor assembling pages for reproduction, comprising the steps of: 

(A) generating a master file containing page descriptions of master pages with fixed information in raster for- 
mat; 

(B) generating a variable file containing page descriptions of variable pages with variable information in raster 
format; 

(C) generating an instruction set for inposlng selected master and variable pages from the raster files; 

(D) RIPping the selected pages according to the instruction set; and 

(E) transmitting the imposed master and variable pages to a display device. 

32. The method of claim 31 . wherein the display device comprises a demand printer. 

33. The method of claim 31 . wherein the display device comprises a computer network. 

34. The method of claim 31 . wherein the raster format comprises TIFF, 
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PRESS COMMAND 
FILE RECORD 
(CREATE IF NEEDED) 



FIG. lOe 
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310 




SELECT NEXT 
RECORD IN DATABASE 
AND CORRESPONDING 
RECORD IN PRESS 
COMMAND FILE 



1 



314 

SELECT FIRST ^ 
PAGE IN SECTION 



316 




"^SIMPLEX 
OR 



'DUPLEX 



SIMPLEX 



DUPLEX 



32S 




COPY MASTER 
PAGE FILE NAME 
AND PG. NUMBER 
AND VARfABLE 
PAGE FILE NAME 
AND PAGE NUMBER 
(IF ANY) AS SINGLE 
SET PAIRS 



COPY MASTER 
PAGE FILE NAME 
AND PG. NUMBER 
AND VARIABLE 
PAGE FILE NAME 
AND PG. NUMBER 
(IF ANY) AS 
SINGLE SET 
PAIRS 



T 



322 



318 



SELECT NEXT 
PAGE IN 
SECTION 



GO TO BLOCK 
170. FIG. 10a 



FI G. 10 f 
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PROMPT USER.TO SPECIFY INFORMATION 
TO CREATE PAGINATION FILE: 
-MAX. # IF PAGES 
-LH/RH FILLER PAGE ID 
FOR EACH PAGE. SPECIFY : 
-FORCE LEFT, FORCE RIGHT OR NO FORCE 
-FILLER PAGE I.D. FOR FORCED PAGE 
-MASTER. ALWAYS VARIABLE OR SELECTIVELY VARIABLE 



340 



OPEN PRESS COMMAND FILE 



342 



I 



SELECT DATABASE FILES, 
PAGINATION FILE, PLACEHOLDERS 
FILE AND BARCODE FILES 



344 



RETRIEVE RECORD IN 
PRESS COMMAND FILE 



346 



DETERMINE WHICH 
PAGES SHOULD 
PRINT 
(SEE FIG. 13) 

i 



/ 



348 



DETERMINE WHETHER 
PAGES ARE LEFT OR RIGHT 
(SEE FI G. 14) 

i 



/ 



350 



"PAD" PAGES INTO 
MULTIPLES OF"N" 
(SEE FIG. 15) 



352 



FIG. 11 



GENERATE POSTSCRIPT® 
INSTRUCTION SET 



354 
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RETRIEVE PAGE FROM 
RECORD IN PRESS 
COMMAND FILE 



348 



CALCULATE AND 
SAVE OFFSETS OF 
ALL PAGES IN FILE 



362 




MARK PAGE 
AS "SHOULD 
PRINT' 



36B^ T 



YES 



FIG. 13 
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INITIALIZE UR 
COUNTER TO "RIGHT" 
(DEFAULT VALUE) 



-380 



350 



-382 



RETRIEVE PAGE 
THAT IS MARKED 
"SHOULD PRINT' 



384 



HAS USER SPECIFIED 
WHETHER PAGE SHOULD 
BE FORCED LEFT OR 
RIGHT? 



NO 



YES 



388 



DOES ORIENTATION MATCH 
USER SPECIFICATION? (I.E. = 
UR COUNTER?) 







386 
r / 




FUR-FLOP 




UR 




COUNTER 


i 

YES 





NO 



MARK APPROPRIATE FILLER 
PAGE AS "SHOULD PRINT' 



-390 



FIG. 14 
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352 

1^ 



COUNT NUMBER OF PAGES ARE 
MARKED "SHOULD PRINT* 
(INCLUDING FILLER PAGES) 



-392 




ADD FILLER PAGES TO 
MAKE IT A MULTIPLE OF 4 



FIG. 15 
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Enter the page height and width of the {mposed page or ^'flat**. These will be used 
as the setpagedevice parameters to the RIP, 



Page Width (Inches): 
Imposition Style: 
Finishing Style: 
Report Field: 



Page Height (Inches): 



11 



1 Get Tiff style 


-I 




In-Une Finishing 


"^1 Four Pagers: 




NO SELECTION 





Stitch 



Bar Code: 
Seletru 



Bottom of Sheet 



3 Page Numbers: Page Numbers Off ^} 




Bar Code PS FUe 
Bar Code Content File 

|VDF IMACOesktop FoIdenVDF Jobs:Longs Drugs:aJoha^m.vars 

jpagPSFae 

IbT Directory 



Device Name: 



Docupnnt 



(^eue Name: 



H8A 



Master and Variable Storage Directory: 



/var/spool/XIUCnps/netc^q 



FIG. 16 
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Open Press 
Command File 



397 



Prompt User to Specify RIP Option; 
Master Only, Variable Only, 
Master & Variable 



FIG. 17 



■398 



^ 

Select First Line In PCF Having 
File Name(s) 




Add to 
RIP List 
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"GET TIFF' 
IMPOSITION 



RETRIEVE PAGE 

PAIR FROM 
INSTRUCTION SET 



10 



RETRIEVE 
REFERENCE TO 
LEFT HAND PAGE IN 
TIFF FORMAT 



12 



MOVE OFFSET TO 
RIGHT SIDE 



14 



RETRIEVE 
REFERENCE TO 
RIGHT HAND PAGE 
IN TIFF FORMAT 



16 



ADD PAGE 
NUMBERS AND/OR 
BAR TRACKING 
CODE 



18 



FIG. 18 
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C Standard Level 2 
SHOWPAGE 
Opera tor 

500 




Reason Code = 0 




502 



Call EndPage 
Procedure 



504 




YES- 



510 



INITGRAPHICS 
(Reset Default Matrix 
and Clipping Path) 



Increment 
PageCount 



/512 



506 



Transmit Contents of 
Raster Memory to 
Output Device 
(For Rendering) 



ERASEPAGE 
(Clear Raster Memory) 



-508 



FIG. 20 



Call BeginPage / 
Procedure 



.514 
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522 



YES 



524 



i 



Set P1 = Current Path Description 
(Call MakePath Procedure) 



Save Current [CTM] 



526 



528 



Set Virtual [CTM] ^ 



Create Clipping Path Between 
Comers of Virtual Page 



530 



532 



Restore Saved [CTM] 
and 

Cun^ent Path (PI) 



Set PI = 
Empty Path 



FIG. 21 
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Redefined 
TRANSFORM 



S36 



534 




Yes 



Call Standard TRANSFOFIM 
Operator 
(Systemdict_Transform) 



No 



538 



Save Current [CTM] 
on Stack 



Calculate [Operations Matrix] = 
[Current CTM] [Virtual CTM]-1 



540 



FIG. 22 



/ 



Set new [CTMl = 
[Operations Matrix] [System Default Matrix] 



542 



544 



Call Standard TRANSFORM Operator 
(Systemdict_Transform) 



Reset Current [CTM] 
(Saved by block 538) 



546 
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ENABLEVIRTUALDEVICE ) 




FIG. 23 



554 



(Level 1) 



Rename Standard 
Level 1 SHOWPAGE 
Operator 



Yes 



556^ 



552 



558 



Redefine Level 1 
Showpage Operator to 
Emulate Level 2 
Showpage Operator 
(See Fig. 20) 



Load Redefined EndPage 
and BeginPage Procedures 
Into Current Graphics State 
(call setpagedevice) 



Execute BeginPage Procedure 
for First Page 



1/' 



560 



Invoke DisablePageDevice Procedure 
(See Fig. 24) 



562 



Set Virtual DeviceEnabled 
.= True 
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c 



DISABLEPAGE 
DEVICE 



572 



) 



YES 



FIG. 24 



570 




NO (Level 1) 



Is 

PageSize 
Included as 
Operand to 
setpagedevice? 



NO 



YES 



574 



Determine Orientation 
(Portrait or Landscape) 
of PageSize Operand 




57B 



Invoke SetPortrait 
Procedure (Fig. 25) 



Call Redefined Inilgraphics 
and ErasePage Operators 



.582 



Redefine Compatibility Operators 
to Corrent Page Orientation 
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SETPORTRAIT^ 



Portrait to 
Landscape) 




No- 



Yes 



(Landscape 
to Portrait) 



600 



Convert Comer 
Coordinates to 
Landscape Orientation 



\ 


/ 


Translate Origin 
in Positive-x 
Direction 







Rotate 90 degrees 
Counterclockwise 



Set Virtual [CTM] for 
Landscape Orientation 



602 



604 



606 



FIG. 25 



Convert Conner 
Coordinates to 
Portrait Orientation 



Translate Origin 
in Positive-Y . 
^ Direction 



Rotate 90 degrees 
Clock>Anse 



Set Virtual [CTM] for 
Portrait Orientation 



Exchange Values of 
Page Width (PageX) 
and Page Height (PageY) 



622 



624 



Reverse Value of Portrait 
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UJ 
< 



592 



5 94 (urx.ur y) 



(I 



xjly) 



-PAGE X- 




(NEW PAGE Y) 



PORTRAIT -> UVNDSCAPE 

FIG. 26A 



_PAGEX _ 
(NEW PAGE Y) 




•PAGE X 



LANDSCAPE -> PORTRAIT 



FIG. 26B 
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^ SETVIRTUALDEVICE^^ 



630 




632 



634 



Define Virtual Page Size 
[PageX PageY] 



636 



Define Comers of Virtual Page 
[Clipllx. Clipliy, Clipurx, Clipury] 




633 



Invoke Redefined Save 
Operator 
(See Figs. 33 & 35) 
(Optional Procs. Only) 



Set [CTM] to System Default Matrix 
for Current Output Device 
(systemdicljnitmatrix) 



.^-^38 



FIG. 27 



Execute Scale. Translate and 
Rotate Procedures 



Save Resultant Matrix as the 
Virtual [CTM] 
(Stored in DefaultMatrix) 



.--640 



642 



548 



644 



646 




Set Portrait = False 
(Landscape Orientation) 



650 



Set Portrait = True 
(Portrait Orientation) 



Invoke Redefined INITCLIP 
Operator to Set 
Clipping Path Around the 
Border of the Virtual Page 
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c 



IMPOSEJOB 



652 



FIG. 28 



Invoke 
EnableVirtualDevice 
Procedure (Fig. 23) 



653 



Execute Redefined Save 
Operator and Store Saved State 
(Optional Procs. Only) 



I 



654 



Retrieve File/List Pair 
from Instruction Set 



556- 



invoke IMPOSEFILE 
Procedure 
(See Fig. 29) 



...A _ 

"—"I 

Execute Redefined Restore \y 
Operator to Restore State Saved \ 
by Block 654 1 
(Optional Procs. Only) 1 



657 





062 
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c 



IMPOSEFILE 



3 



FIG. 29 



670 



PageOffset = CurrenlPage 
+ PageOffsGt + 1 



^ , . 



672 



673 



674 



Retrieve Entry from Entry List 
[{user proc} page # (operands) 
{user proc)] 



CurrentPage = 
Page # from Entry 



578 




675 



Invoke SetVirtualDevice 
Procedure (See Fig. 27) 




Execute 

User 
Procedure 



YES 



676 



Pop 
User 
Procedure 



Invoke MakeNull Procedure 
(see Rg. 30) 
For Scaled-Down Virtual Device 
(INtTCLlP) 



Find Last Page 
on Flat 



582 



Interpret Page Descriptions 
(containing SHOWPAGE Operator) 
in PostScript File Through Last Page 



86 



688 



690 



Flush File and 
Close File 



Get Next File/List Pair 
from IMPOSEJOB 
Procedure 
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C ^^N"*-^ ) FIG. 30 



Calculate and Save MidPoint 
of 

Virtual Clipping Path 
in Device Space 


695 

/ 


y 


\f 


700 


Get Virtual [CTM] 
(Stored in DefaultMatrix) 


/ 


N 


f 


702 

/ 


Calculate Sx and Sy 
Scale Factors 


V 


i 


704 


Scale Virtual [CTM] 


/ 

/ 






706 

/ 


Store Scaled Virtual [CTM] 
as the New Virtual [CTM] 
in DefaultMatrix 



"iU - 

Set MidPoint of Scaled Clipping Path 
Equal to Original 
Midpoint Coordinates 
(Saved by Block 698) 
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7U 



713 



720 



722 



724 



726 



(Redefined N 
EndPage J 




No 



No 



716 




No 



Reset Graphics State to Default 
(systemdictjnitgraphics) 



Retrieve Entry from Entry List 
(Operands to setvirlualdevice) 



Invoke setvirtualdevice Procedure 



CurrentPage = Page Number from 
Retrieved Entry (Next Page on Flat) 



FIG. 31 







Execute Second 


Yes 




User Procedure 




(Offsets) 


Increment Currentlndex to Get 




\ 


Next Entry from Entry List 


< 


713 



730 



Get Value of ImageDone 
('True" means flat is complete) 



Reset ImageDone to False 



732 



Invoke MakeNull Procedure (Fig. 30) 
(assume next page not on flat) 



Pop User 
Procedure 



-728 
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c 



Redefined 
BeginPage 



740 



Set Virtual [CTM] 
(redefined INITMATRIX) 



Get Entry from 
Entry/List Pair 



Execute User 
Procedure 



I 



745 



FIG. 32 




NO— > 



756 



Invoke 
Redefined 
INITCLIP 
Operator 
(See Fig. 21) 



STOP 
"Done with 
Current File" 



Invoke SetVirtualDevice 
Procedure (See Fig. 27) 



746 



74a 



750 



Pop Page Number from 
Retrieved Entry 



Blank Out Virtuaf Page 
(Erase Any Stray Marks 
from Non-Selected Pages) 
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^ VSAVE J 





/ 


Save Current [CTM] 




( 


Set [CTM] = 
Identity Matrix 



./aoo 



FIG. 33 



^801 




808 



Set PI = No-op 
(Empty) Path 



Set P1 = Current Path 
(Invoke MakePath 
Procedure) 



FirstOp = Moveto 
(Set CurrentPoint) 



FirstOp = Lineto 
(Add Segment to 
Cun-ent Path) 



Create Unlimited 
Bounding Box 
(SetSigBBox) 



806 



812 



814 



Invoke FirstOp to Append Page 
Size (PageX and PageY) 
Components to Current Path 



> 

Append Vir 
Compof 
Currer 


f 

lual [CTM] 
lents to 
It Path 




f 


Replace Identity [CTM] with 
Previously Saved [CTM] 



818 



820 
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r VRESTORE J 



330 



Save Current [CTM] 



832 



FIG. 34 



Set [CTM] = Identity Matrix 



Retrieve Current Path Operands (includes page 
size & virtual [CTM] components at time of save) 



836 



Set ResDefaultMatrix and ResPageSize to [CTM] 
and Page Size from Current Path (at time of save) 




Set [CTM] to Value Saved 
by Block 830 



Set PI = Path at Time of Save 
(without PageSize and [CTM]) 



42 



Yes 

N 


856 

, / 


Remove Page Size and Virtual 
[CTM] Components from 
Current Path 






Restore Current Path 


\* 




Restore [CTM] to Value 
Saved by Block 830 



846 



Change Page 
Orientation 

(Invoke 
SetPortrait 
Procedure) 




852- 



Execute Correct Clipping Path (C1) 
in Virtual [CTM] Coordinate System 



854^ 



Restore Current Path (P1) 
in Virtual [CTM] Coordinate System 
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Redefined 
SAVE/GSAVE 



872 



Invoke VSAVE 
Procedure (Fig. 33) 



874 



Invoke Renarned 
Standard Save/GSave 
Operator 



Set [CTM] = 
Identity Matrix 



876 



Restore Current Path 
(Saved in P1) 



878 



880 



Restore [CTM] Saved by 
Block 500 of VSAVE 
Procedure (Fig. 33) 



/ 



FIG. 35 



FIG. 37 



Redefined 
RESTORE 



3 



Put Values of 
Variables on 
Operand Stack 



Invoke Renamed 
Standard Restore 
Operator 



Set Variables Equal 
to Their Pre-Restore 
Values (saved on 
Operand Stack) 



invoke VRESTORE 
Procedure 
(See Fig. 34) 



FIG. 36 



692 



394 



896 



898 



Redefined 
GRESTORE/ 
GRESTOREALL 



902 




> 




\ 


Invoke Renamed Standard 
Grestore/Grestoreall Operator 






> 






904^ 




Invoke VRESTORE Procedure 
(See Fig. 34) 
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